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Abstract 

It  should  be  no  surprise  that  Department  of  Defense  (DoD)  and  U.S.  Air  Force 
(USAF)  networks  are  the  target  of  constant  attack.  As  a  result,  network  defense 
remains  a  high  priority  for  cyber  warriors.  On  the  technical  side,  trust  issues  for  a 
comprehensive  end-to-end  network  defense  solution  are  abundant  and  involve  multiple 
layers  of  complexity.  The  Air  Force  Research  Labs  (AFRL)  is  currently  investigat¬ 
ing  the  feasibility  of  a  holistic  approach  to  network  defense,  called  Gybercraft.  We 
envision  Gybercraft  to  be  trusted  computer  entities  that  cooperate  with  other  Gyber¬ 
craft  to  provide  autonomous  and  responsive  network  defense  services.  A  top  research 
goal  related  to  Gybercraft  centers  around  how  we  may  examine  and  ultimately  prove 
features  related  to  this  root  of  trust. 

In  this  work,  we  investigate  use-case  scenarios  for  Gybercraft  operation  with  a 
view  towards  analyzing  and  expressing  trust  requirements  inherent  in  the  environ¬ 
ment.  Based  on  a  limited  subset  of  functional  requirements  for  Gybercraft  in  terms  of 
their  role,  we  consider  how  current  trust  models  may  be  used  to  answer  various  ques¬ 
tions  of  trust  between  components.  We  characterize  generic  model  components  that 
assist  in  answering  questions  regarding  Gybercraft  trust  and  pose  relevant  comparison 
criteria  as  evaluation  points  for  various  (existing)  trust  models.  The  contribution  of 
this  research  is  a  framework  for  comparing  trust  models  that  are  applicable  to  similar 
network-based  architectures.  Ultimately,  we  provide  a  reference  evaluation  framework 
for  how  (current  and  future)  trust  models  may  be  developed  or  integrated  into  the 
Gybercraft  architecture. 
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Developing  a  Reeerence  Framework 
EOR  Cybercraet  Trust  Evaluation 

I.  Introduction 

The  world  is  in  the  middle  of  the  information  age  with  almost  anything  easily 
accessible  through  the  Internet.  Attackers  are  everywhere  exploiting  this  wealth 
of  information  and  targeting  U.S.  military  information  systems.  Working  towards 
combating  these  new  threats,  the  USAF  redehned  its  mission  in  2005  to  include 
cyberspace  -  “deliver  sovereign  options  for  the  defense  of  the  United  States  of  America 
and  its  global  interests  -  to  fly  and  hght  in  Air,  Space,  and  Cyberspace.”  [9]  The 
strategic  vision  for  Cyberspace  as  a  warhghting  domain  was  furthered  by  Secretary  of 
the  Air  Force  Michael  W.  Wynne  when  he  announced  the  creation  of  the  Cyberspace 
Command  (AFCYBER)  [13].  Focusing  on  science  and  technology  issues  related  to 
this  domain,  AFRL  launched  a  research  initiative  geared  to  prepare  for  defense  in  this 
critical  realm  of  cyberspace,  termed  Cybercraft.  Just  as  aircraft  platforms  operate  in 
air  and  carry  a  wide  variety  of  payloads  (bombs,  missiles,  electronic  warfare  pods, 
precision  guided  munitions),  the  term  Cybercraft  reflects  the  idea  of  generic  platforms 
operating  in  cyberspace  and  executing  a  wide  variety  of  payloads  (patch  verihcation, 
router  conhguration  information,  INFOCON  policy  enforcement,  etc.). 

The  likely  Cybercraft  architecture  consists  of  a  machine-installed  platform  that 
executes  mission-specihc  payloads:  the  platform  represents  a  trusted  component  that 
provides  command,  control,  and  communication  of  cyber  capabilities  on  host  nodes 
while  the  payloads  inherit  trust  from  the  platform  and  carry  out  various  defensive 
missions  and  goals.  Network  defenders  will  use  this  architecture  to  accomplish  specihc 
tasks  via  single  or  multiple  cooperating  Cybercraft  payloads.  The  architecture  will 
incorporate  hybrid  trusted  hardware/software/hrmware  components  in  various  levels 
of  interaction  to  support  desired  functionalities  such  as  intrusion  detection,  anti-virus 
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monitoring,  network  defense,  and  so  forth.  Cybercraft  may  eventually  be  deployed  on 
up  to  one  million  nodes  in  order  to  provide  commanders  with  a  root  of  trust  related 
to  their  high  level  strategic  and  operational  network  defense  needs. 

1.1  Research  Motivation 

1.1.1  Goals.  The  ability  to  model,  measure,  and  verify  the  degree  of  trust  a 
commander  may  place  in  Cybercraft  remains  a  crucial  research  question  that  must  be 
adequately  characterized  before  this  future  architecture  becomes  a  reality.  Although 
trust  itself  has  a  multitude  of  meanings,  in  this  work  we  consider  how  to  synthesize  and 
express  the  nature  of  trust  in  the  future  Cybercraft  environment  based  on  expected 
operational  requirements.  We  further  characterize  generic  model  components  that 
will  help  answer  questions  regarding  Cybercraft  trust  and  pose  relevant  comparison 
criteria  as  evaluation  points  for  various  (existing)  trust  models.  We  also  introduce  a 
novel  approach  to  synthesize  trust  relationships  iteratively  based  on  use  case  analysis, 
attack  tree  threat  modeling  and  operational/mission  level  task  breakdown. 

1.2  Research  Contribution 

1.2.1  Requirements.  We  provide  a  unique  and  revolutionary  approach  to 
requirements  definition  based  on:  use  case  analysis,  attack/defense  trees  and  mission 
level  task  breakdown.  Attack  trees  are  a  way  to  visualize  attacks  on  our  networks  as 
well  as  possible  defense  approaches  to  these  attacks.  A  use  case  is  typically  described 
as  a  text-based  step-by-step  breakdown  of  the  interaction  between  a  user  and  a  system. 
Mission  level  task  breakdown  is  the  process  of  splitting  a  high  level  goal  into  smaller, 
more  manageable  pieces.  Our  initial  set  of  requirements  helps  further  the  goal  of 
creating  a  Cybercraft  prototype. 

1.2.2  Reference  Framework  for  Trust  Evaluation.  Our  contribution  to  the 
area  of  trust  is  creating  a  way  to  characterize  generic  model  components  to  establish 
trust  boundaries  within  the  Cybercraft  domain.  Given  specific  requirements  specifi¬ 
cation,  we  derive  attributes  and  desired  properties  of  trust  models  which  articulate. 
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express,  and  evaluate  commanders  trust.  We  provide  specific  correlation  between 
abstract  trust  models  and  the  Cybercraft  trust  problem  related  to  specific  system  re¬ 
quirements.  Furthermore,  we  implement  and  analyze  specific  models  to  demonstrate 
the  utility  of  trust  expression  within  the  context  of  Cybercraft.  Given  three  specific 
trust  models  (hTrust,  VTrust,  P2P),  we  illustrate  and  analyze  the  nature  of  transitive 
trust  decisions  reflected  by  components  of  the  Cybercraft  architecture.  Finally,  we 
define  a  reference  framework  for  evaluating  existing  and  future  trust  models  as  well 
as  provide  specific  measures  for  analyzing  transitive  trust  relationships  in  view  of  the 
Cybercraft  platform  and  its  root  of  trust. 

1.3  Thesis  Organization 

This  document  is  divided  into  seven  chapters.  Chapter  II  presents  Cybercraft 
and  trust  issues  in  greater  detail.  Chapter  III  presents  our  approach  to  requirements 
gathering  using  attack/defense  trees,  use  cases  and  mission  level  task  breakdown. 
Chapter  IV  characterizes  the  trust  models  and  further  explains  how  to  evaluate  them. 
Chapter  V  sets  up  the  scenarios.  Chapter  VI  walks  through  and  analyzes  the  results 
and  Chapter  VII  summarizes  our  contributions  and  give  recommendations  for  future 
work. 

Thesis  Statement:  This  research  examines  the  trust  relationships  throughout 
the  Cybercraft  architecture  and  develops  a  clear  way  of  gathering  requirements  by 
using  attack  trees,  use  cases  and  mission  level  task  breakdown. 

Results:  This  research  creates  an  initial  set  of  requirements  for  the  Cybercraft 
Domain  (Chapter  III,  Section  3.3).  These  requirements,  along  with  three  trust  models 
(hTrust,  VTrust,  P2P),  create  a  reference  framework  for  Cybercraft  trust  evaluation. 
Analysis  of  the  three  trust  models  concludes  no  model  rises  above  another  and,  as  is, 
none  are  suitable  for  potential  use  within  the  Cybercraft  architecture. 

This  research  first  creates  an  initial  set  of  requirements  for  the  Cybercraft  do¬ 
main  (Chapter  III,  Section  3.3).  Next,  we  create  a  referece  framework  for  trust 
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model  evaluation  with  possible  application  to  Cybercraft.  Three  models  in  particular 
(hTrust,  VTrust,  P2P)  were  evaluated  to  create  the  reference  framework  (Chapter  VI, 
Section  6.3).  Our  analysis  of  the  three  models  concludes  that  none,  in  their  current 
state,  are  applicable  for  Cybercraft.  Using  the  reference  framework  as  a  guide  for 
trust  model  requirements,  a  combination  of  the  best  attributes  of  the  three  models  is 
a  possibility. 
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II.  Related  Work 


Defining  trust  is  elusive  as  no  one  definition  rises  above  another.  One  of  the 
reasons  is  that  trust  is  more  of  a  social  issue  as  opposed  to  the  technical  view 
many  in  the  research  community  have. 

Although  trust  is  used  everywhere,  Gollmann  argues  that  just  using  the  word 
(trust)  in  a  system  or  project  is  dangerous  because  of  its  manifold  and  sometimes 
contradictory  meanings  [10].  It  is  an  overloaded  term  that  hinders  the  clarity  and 
precision  that  is  sought  after  in  technical  helds.  Nonetheless,  it  expresses  a  quality 
that  military  commanders  make  quite  frequently:  an  objective  dependability  (whether 
by  mathematical  proof  or  demonstrated  testing)  that  a  system  will  perform  according 
to  its  specihcations,  even  though  negative  consequences  can  occur.  Next,  we  dis¬ 
cuss  the  specihc  ideas  of  trust  that  apply  to  Cybercraft  in  context  to  the  envisioned 
architecture. 

2. 1  Trust 

Many  authors  have  attempted  to  dehne  trust.  Gambetta  [8]  laid  the  founda¬ 
tion  for  the  dehnition  of  trust  as  a  social  concept  that  is  subjective  and  context- 
dependent.  Cahill  [4]  elaborated  further  to  add  attributes  such  as  self-preserving  and 
self-amplifying,  among  others.  In  more  general  terms,  trust  is  dehned  as  the  measure 
of  trustworthiness  that  relies  on  whatever  evidence  is  provided  or  implied  [3].  Trust 
plays  a  key  role  in  system  development  and  we  consider  it  an  essential  concept. 

To  understand  trust,  many  look  at  and  try  to  mimic  human  trust  [4,  5]  and 
consider  three  main  delineations:  initial  trust,  trust  evolution,  and  trust  delegation. 
Initial  trust  is  the  hrst  formation  of  trust  between  two  entities  and  usually  happens 
through  recommendations  from  other  trusted  entities.  Trust  evolution  is  the  contin¬ 
uation  and  self-adaptation  of  trust  over  time  and  allows  for  experience  to  affect  the 
trust  relationship.  Trust  delegation  occurs  when  an  entity  delegates  a  trust  decision 
to  another  trusted  entity.  In  other  trust  domains  [17],  different  terms  express  the 
same  basic  concepts:  experience  (for  evolution),  knowledge  (initial),  recommenda- 
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tions  (delegation).  Once  we  assign  a  precise  meaning  and  definition  for  trust,  we  in 
essence  form  a  model  which  may  be  exercised  and  evaluated  given  the  assumptions 
and  boundaries  of  our  system.  It  is  essential  that  regardless  of  the  model  chosen,  the 
reason  we  want  to  use  the  model  and  our  expectation  of  what  it  will  provide  must  be 
clearly  defined. 

2.2  Transitive  Trust 

We  are  especially  interested  in  the  idea  of  transitive  trust  for  application  to 
Cybercraft.  The  goal  is  to  have  many  Cybercraft  working  together  in  the  same  envi¬ 
ronment  to  accomplish  a  set  of  goals.  There  will  be  times  when  Cybercraft  A  must 
trust  Cybercraft  B  with  a  trust  decision  on  whether  or  not  to  interact  with  Cyber¬ 
craft  C.  In  a  more  general  sense,  two  entities  can  have  varying  degrees  of  trust  in 
each  other,  within  a  specific  context.  An  entity  can  trust  an  individual  in  multiple 
contexts  as  well,  each  having  a  different  value  of  trust.  We  can  express  transitive  trust 
as  the  resulting  measure  between  an  entity  A  and  entity  C  based  on  the  assumption 
that  entity  A  trusts  entity  B  and  entity  B  trusts  entity  C.  Our  interest  in  transitivity 
permeates  a  basic  desire  for  Cybercraft:  the  ability  to  take  a  locality  of  guaranteed 
trust  (established  through  hardware)  and  extend  that  trust  to  the  execution  of  code 
(via  payloads)  so  that  the  resulting  effects,  collected  data,  sensing  information,  and 
network  operations  are  trusted  as  well.  The  other  aspect  of  trust  we  must  consider 
deals  with  the  multi-agent  communication  and  cooperation  needs  that  become  evident 
when  considering  a  typical  Cybercraft  application  involving  multiple  payloads  oper¬ 
ating  across  multiple  platforms.  Both  of  these  application  contexts  have  ramifications 
for  Cybercraft  and  our  desire  to  express  and  measure  commander-level  trust. 

2. 3  Cybercraft 

Phister  et  ah  [15]  pose  the  first  conceptual  use  of  Cybercraft  as  an  autonomous, 
intelligent  agent  that  accomplishes  military  purposes  across  a  wide  variety  of  electronic- 
based  media.  Envisioned  as  a  cyber-vehicle  that  traverses  through  cyberspace,  Cy- 
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bercraft  were  seen  as  the  future  platform  by  which  military  operations  would  be 
conducted  in  the  cyber  realm.  AFRL  enhanced  these  ideas  [2]  and  developed  plat¬ 
form/payload  architecture  with  certain  target  qualities.  The  Cybercraft  platform, 
for  example,  requires  a  long  service  life  with  large  investment  to  support  a  variety 
of  missions  and  will  be  the  subject  of  intense  scrutiny  to  characterize  attribution, 
authentication,  and  reliability.  The  Cybercraft  payload,  likewise,  supports  rapid  de¬ 
velopment  cycles,  provides  extensibility,  and  implements  specific  effects  related  to 
defensive  missions.  The  long  service  life  of  the  platform  allows  for  trust  to  be  formed, 
maintained,  and  reevaluated  on  a  constant  basis.  As  research  has  progressed,  trust 
and  a  self-protection  guarantee  for  Cybercraft  have  emerged  as  a  coherent  study 
area  [11, 14]. 

We  can  use  a  domain  model  to  describe  various  relationships  between  entities 
in  a  system.  Figure  2.1  illustrates  a  rudimentary  domain  model  for  Cybercraft  that 
illustrates  several  concepts  pertinent  to  trust  expression  and  security.  First  of  all,  the 
platform  has  a  one-to-many  relationship  with  prospective  nodes,  meaning  that  one 
platform  will  be  deployed  per  node  and  nodes  represent  a  wide  variety  of  IP-based 
appliances  such  as  workstations,  routers,  hand-held  devices,  or  servers.  Currently, 
Cybercraft  platforms  will  execute  payloads  to  achieve  or  accomplish  specific  effects 
and  goals  in  support  of  operational/tactical  missions.  Platforms  may  communicate 
with  other  platforms  or  allow  inter-payload  communication  to  accomplish  their  tasks. 
Platforms  (and  thus  payloads)  may  also  use  other  tools  or  processes  (virus  checkers, 
IDS,  etc.),  depending  on  the  level  of  trust  such  tools  may  have.  Though  the  entire 
cyber  environment  is  not  represented,  we  can  still  visualize  that  nodes  are  connected 
to  other  nodes  via  networks  and  are  ultimately  controlled  by  some  underlying  op¬ 
erating  system  (OS).  The  specific  relationship  between  the  Cybercraft  platform  and 
a  deployment  node  is  still  under  consideration,  but  the  current  direction  assumes  a 
mixture  of  hardware  and  firmware  that  is  independent  of  normal  architectural  layout. 

The  tentative  domain  model  in  Figure  2.1  reflects  the  complexity  of  the  trust 
evaluation  process.  Payloads  are  seen  to  inherit  trust  from  the  Cybercraft  platform 
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Figure  2.1:  Conceptual  Domain  model  for  Cybercraft. 

and  each  association  represents  a  possible  trust  decision  that  requires  evaluation. 
There  will  have  to  be  an  initial  trust  value  for  a  Cybercraft  to  trust  the  machine  it 
is  loaded  to.  Computer  networks  are  constantly  changing  and  so  as  time  goes  on, 
trust  evolution  and  delegation  will  need  to  be  addressed.  As  this  domain  model  is 
conceptual  and  by  no  means  as  extensive  and  complex  as  the  Cybercraft  domain, 
it  illustrates  the  need  for  a  way  to  measure  trust  between  all  the  interacting  parts. 
Thompson  [20]  demonstrated  through  a  series  of  examples  that  it  was  impossible  to 
trust  any  code  unless  personally  written.  AFRL  has  an  Anti-Tamper  program.  Soft¬ 
ware  Protection  Initiative  (AT/SPI)  whose  mission  is  ”to  prevent  the  unauthorized 
distribution  and  exploitation  of  application  software  critical  to  national  security”  [1]. 
Combining  these  techniques  with  trust  model  exploration  will  only  enhance  the  goal 
of  trusted  relationships  for  the  Cybercraft  architecture. 

Establishing  a  Root  of  Trust 

We  dehne  a  fundamental  aspect  of  trust  in  Cybercraft  as  the  ability  for  a  system 
to  behave  as  designed  and  intended.  The  notion  of  a  root  of  trust  based  on  hardware 
that  cannot  change  is  not  new  -  and  in  fact  has  been  a  prized  goal  for  organizations 


such  as  the  Trusted  Computing  Group  (TCG)  for  quite  some  time  [21],  TCG  spec- 
ihcations  provide  a  starting  point  for  an  open  set  of  security  related  building  blocks 
that  will  associate  trust  with  all  aspects  of  computing  to  include  storage,  network¬ 
ing,  software,  mobile  devices,  personal  computers,  and  servers.  Two  serious  concerns 
for  trusted  computing  standards  such  as  those  sponsored  by  TGG  include  the  notion 
that  competition  may  be  stifled  or  that  manufacturers  may  implement  their  “trusted” 
components  incorrectly.  In  the  context  of  Gybercraft,  the  former  concern  is  not  an 
issue  as  the  military  environment  provides  the  operational  bounds  and  the  latter  con¬ 
cern  would  need  to  be  addressed  adequately  with  any  proposed  Gybercraft  platform 
solution.  Nonetheless,  the  movement  towards  implementable  and  procurable  secure 
hardware  solutions  in  the  commercial  market  provides  perfect  overlap  with  Gybercraft 
goals  to  integrate  such  technology. 

We  may  liken  trust  establishment  in  hardware,  software,  or  even  the  network 
itself  to  the  establishment  of  trust  with  a  service  organization.  TGG  propose  the  use 
of  silicon-based  components  such  as  the  Trusted  Platform  Module  (TPM)  as  a  source 
of  trusted  storage  where  keys  or  passwords  may  be  stored.  At  a  minimum,  we  require 
a  boot-time  process  to  ensure  secure  conhguration  of  all  further  system  activity  in 
order  for  the  Gybercraft  platform  to  establish  the  root  of  trust.  We  need  to  hnd  trust 
models  to  capture  this  Gybercraft  aspect  and  models  which  exercise  further  transi¬ 
tive  relationships  past  the  platform.  Gandidate  trust  models  should  also  address  the 
possibility  of  physical  compromise  (capture  and  subjection  of  hardware/software  to 
adversarial  activity)  for  either  the  platform  or  any  possible  payload.  TGG  already 
distinguishes  different  roots  of  trust  including  measurement,  storage,  and  reporting, 
which  hnd  close  corollary  to  proposed  parts  of  the  Gybercraft  platform.  In  the  trusted 
computed  realm,  we  consider  attestation  as  the  processes  for  guaranteeing  the  accu¬ 
racy  of  information  and  the  ability  of  a  platform  to  vouch  for  the  trustworthiness  of 
another  platform.  Attestation  also  provides  a  parallel  notion  for  a  major  perceived 
computing  paradigm  supported  by  the  Gybercraft  architecture  involving  multi-agent 
cooperation  between  payloads  accomplishing  common  tasks  and  goals. 
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The  root  of  trust  established  in  hardware  for  the  Cybercraft  platform  gives  us 
the  basis  for  analyzing  transitive  trust  decisions  and  gives  us  a  framework  to  analyze 
possible  trust  models.  In  order  to  address  how  we  may  integrate  these  models  into 
the  development  for  Cybercraft,  we  begin  with  our  approach  for  capturing  functional 
and  non-functional  requirements,  which  we  discuss  next. 

2.5  Cybercraft  Requirements  Distillation 

One  of  the  first  steps  in  creating  software  is  defining  what  it  will  be  used  for, 
in  other  words,  requirements.  Current  practices  for  software  development  include  the 
use  of  an  iterative  approach  which  assumes  change  and  relies  heavily  on  feedback,  this 
is  the  Object  Oriented  Analysis  and  Design  (OOA/D)  and  Iterative  Development  pro¬ 
cess.  We  apply  the  Iterative  Development  [12]  as  a  model  by  which  we  can  perform 
iterative  analysis  and  design  for  the  Cybercraft  architecture  while  collectively  identi¬ 
fying  and  refining  requirements.  While  some  aspects  of  the  future  Cybercraft  vision 
may  still  be  in  the  realm  of  research  and  development,  the  basic  requirements  for  the 
system  derive  from  a  desire  to  provide  comprehensive  network  defense  services  in  a 
holistic  and  secure  manner.  The  requirements  for  such  a  system  are  enormous  to  say 
the  least  and  in  order  to  know  where  to  start,  we  begin  with  a  general  understanding 
of  network  defense  missions  as  they  are  currently  conducted.  However,  in  order  to 
capture  the  needs  of  a  future  system  versus  the  closed  context  of  current  systems,  we 
seek  to  define  the  network  defense  role  from  a  general  application  perspective.  To  ac¬ 
complish  this  task  we  use  distinct  techniques  in  conjunction:  attack/defense  trees  [6] 
and  use  cases  [12]. 

2.5.1  Attack  /  Defense  Trees.  If  we  had  free  reign  to  design  a  holistic 
approach  to  network  security,  based  on  an  extensible  architecture  that  uses  mission- 
specific  co-operating  payloads,  we  may  best  discover  the  possible  tasks  of  the  payloads 
by  looking  first  at  the  possible  ways  our  network  is  attacked.  Attack  trees  provide  a 
textual  and  visual  means  to  analyze  such  attacks  upon  a  system  and  are  useful  tools  to 
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reason  about  system  security.  Figure  2  shows  an  example  attack  tree  where  the  root 
node  is  the  attackers  goal  and  the  children  nodes  show  means  or  ways  the  attacker 
could  accomplish  an  attack  goal.  The  tree  may  have  AND  nodes  which  mean  all  child 
nodes  must  be  successful  to  achieve  the  main  goal.  Trees  use  OR  nodes  to  represent 
that  only  one  of  its  child  nodes  need  to  succeed  for  its  path  to  be  successful  [6]. 

Once  we  exhaustively  consider  how  our  networks  may  be  attacked  and  document 
those  in  the  form  of  attack  trees,  we  can  then  know  best  what  a  network  defense 
architecture  should  be  doing  in  response.  For  Cybercraft,  we  apply  this  approach 
iteratively  by  taking  specihc  attacks  and  creating  defense  trees  in  response.  Defense 
trees  outline  the  possible  mitigating  actions  we  may  take  in  response.  The  defense 
tree  corresponds  to  the  leaf  nodes  of  the  attack  tree  and  provides  us  a  task’  level 
understanding  of  what  needs  to  be  done.  The  root  node  is  the  attackers  goal  and  the 
children  nodes  are  means  or  ways  the  attacker  could  accomplish  that  goal.  Figure  2.2 
illustrates  an  example  attack  tree  as  dotted  lines  and  in  this  case  shows  that  a  DDoS 
attack  may  be  defended  against  using  hrewall/switch/router  ACLs  or  an  intrusion 
detection  system  (IDS).  Figure  2.3  shows  the  difference  between  and  AND  and  an 
OR  node.  Though  very  high  level  and  general  in  this  example,  we  envision  such 
attack/defense  tree  modeling  will  provide  a  root  level  of  understanding  for  possible 
Cyber  craft  tasks. 

Once  attack/defense  trees  are  developed,  we  take  some  small  starting  number 
of  trees/branches  (our  most  important  roles  for  example).  We  then  analyze  whether 
those  defensive  roles  are  currently  being  done  by  a  human,  an  existing  tool,  or  both. 
In  some  cases,  there  may  be  no  (effective)  current  method  that  mitigates,  detects,  or 
prevents  certain  attacks.  This  analysis  method  gives  us  a  basis  to  determine  whether 
we  want  the  Cybercraft  platform/payload  architecture  to  do  a  particular  task,  do  a 
current  task  better,  or  possibly  automate  an  existing  human-driven  process.  This 
process  gives  us  the  chance  to  not  only  analyze  how  well  (or  not)  we  currently  do 
network  defense,  but  also  gives  us  the  ability  to  look  into  future  requirements  without 
limitation  of  what  currently  is  possible. 
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Figure  2.2:  Attack  tree  created  for  an  attack  on  network  infrastructure. 


Figure  2.3:  Attack  tree  demonstrating  and  AND  and  OR  node. 

2.5.2  Use  Cases.  Once  we  determine  defensive  roles  that  are  applicable 
to  Cybercraft,  we  utilize  a  standard  means  for  capturing  software  requirements  for 
those  roles:  use  cases.  Use  cases  are  textual  means  of  describing  the  step-by-step 
interaction  between  a  user  and  a  system.  In  the  case  of  Cybercraft,  we  expect  that  text 
stories,  diagrams,  and  models  will  help  us  determine  not  only  functional  requirements 
for  payloads,  but  also  non-functional  requirements  related  to  command  and  control, 
visualization,  and  policy  development.  Because  use  cases  are  software  methodology 
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agnostic,  they  provide  an  ideal  means  to  commnnicate  requirements  between  users, 
analysts,  and  designers.  Use  cases  provide  a  concrete  means  to  further  determine  the 
nature  and  number  of  payloads  that  support  a  given  defensive  role  or  mission.  They 
also  provide  the  ideal  means  to  analyze  the  impact  of  transitive  trust  relationships  in 
a  concrete  manner. 

Not  only  do  Cybercraft  requirements  need  to  address  how  we  intend  to  perform 
network  defense,  they  also  need  to  uniformly  address  all  possible  avenues  of  vulnera¬ 
bility.  We  see  the  nature  of  the  trust  question  most  clearly  in  this  context  as  it  forces 
us  to  consider  possible  ways  in  which  the  actual  Cybercraft  may  itself  be  subverted. 

We  use  scenarios,  dependencies,  and  any  implementation  assumptions  as  part 
of  the  analysis  process  to  help  identify  trust  expressions  (or  questions)  that  should  be 
evaluated  or  answered.  To  aid  in  this  process,  we  also  apply  the  art  of  misuse  cases  to 
the  normal  use  case  process.  Misuse  cases  are  simply  step-by-step  descriptions  that 
detail  adversarial  action  and  records  how  the  system  (should  or  should  not)  respond 
accordingly.  We  expect  this  analysis  to  directly  feed  our  requirements  for  trust  model 
expression  and  exercise. 

The  general  template  of  a  use  case  is  shown  in  Table  2.1.  For  most  of  the 
requirements,  we  will  use  brief  use  cases  and  thus  have  only  line  describing  the  action. 


2.6  Trust  Models 

In  order  to  address  the  issue  of  self  protection  and  trust,  we  consider  the  unique 
aspects  of  the  Cybercraft  architecture  that  need  trust  model  expression  and  that  are 
revealed  as  part  of  the  requirements  analysis  process.  We  consider  several  models 
such  as  hTrust  [5],  VTrust  [16,17],  and  P2P  [22].  hTrust  ,  mimics  the  interactions 
of  humans  trust  and  works  well  in  mobile  settings  because  of  the  minimal  resource 
demands.  VTtrust  ,  is  a  vector-based  trust  model.  Trust  interactions  are  represented 
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Table  2.1:  Use  case  template  [12], 


Use  Case  Section 

Comment 

Use  Case  Name 

Start  with  a  verb 

Scope 

The  system  under  design 

Level 

user-goal  or  sub-function 

Primary  Actor 

Calls  on  the  system  to  deliver  services 

Stakeholders  and  Interests 

Who  cares  about  this  use  case,  and  what  do 
they  want? 

Preconditions 

What  must  be  true  on  start,  and  worth 
telling  the  reader? 

Success  Guarantee 

What  must  be  true  on  successful  completion, 
and  worth  telling  the  reader? 

Main  Success  Scenario 

A  typical,  unconditional  happy  path  scenario 
of  success 

Extensions 

Alternate  scenarios  of  success  or  failure 

Special  Requirements 

Related  non-functional  requirements 

Technology  and  Data  Variations  List 

Varying  I/O  methods  and  data  formats 

Frequency  of  Occurrence 

Influences  investigation,  testing,  and  timing 
of  implementation 

Miscellaneous 

Such  as  open  issues 

as  relational  entities  translated  to  a  central  database.  Peer-to-peer  is  a  trust  model 
applied  to  peer-to-peer  systems. 

For  each  trust  model,  there  are  three  components  of  trust:  initial  trust,  trust 
exchange,  and  trust  evolution.  Initial  trust  is  the  hrst  formation  of  trust  between 
two  agents.  Trust  exchange  deals  with  the  protocols  and  exchange  of  trust  between 
agents.  Trust  evolution  is  the  continuation  of  trust  over  time.  This  allows  for  the 
decay  of  knowledge  that  happens  over  time.  Each  trust  model  uses  various  words  for 
each  of  these  trust  ideas  but  essentially  mean  the  same  thing.  Table  2.2  shows  each 
model  with  their  terms. 


2.6.1  hTrust.  hTrust  [5]  is  made  up  of  three  main  parts:  trust  formation, 
trust  dissemination,  and  trust  evolution.  Trust  formation  is  the  initial  trust  before 
an  interaction  occurs;  creating  a  trusting  environment  that  gives  us  a  prediction  of 
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Table  2.2:  A  summary  of  similar  trust  ideas  for  each  trust  model 


Trust  Model 

Initial  Trust 

Trust  Exchange 

Trust  Evolution 

hTrust 

formation 

dissemination 

evolution 

VTRUST 

knowledge 

experience 

recommended 

P2P 

ratings  generation 

ratings  discovery 

ratings  aggregation 

trustworthiness.  Trust  dissemination  uses  a  recommendation  exchange  protocol  to 
exchange  trust  opinions.  The  evolution  of  trust  is  the  part  that  allows  for  a  continuous 
self-adaptation  of  trust. 

2. 6. 1.1  Trust  Formation.  Trust  formation  is  the  initial  trust  before 
an  interaction  occurs;  creating  a  trusting  environment  that  gives  us  a  prediction  of 
trustworthiness.  To  create  the  initial  trust  between  two  agents  (say  agents  a  and  b), 
the  aggregated  trust  information,  recommendations,  and  trust  formation  function  T 
are  all  used. 

The  aggregated  trust  information  is  made  up  of  a  set  of  tuples,  as  shown  in 
equation  2.1. 


[a,b,l,s,c,k,t]  (2.1) 

It  is  read  as  agent  a  trusts  agent  b  at  level  I  to  do  service  s  in  context  c.  The  trust 
level  I  is  a  real  value  in  the  range  of  [-1,1],  -1  being  total  distrust  and  1  blind  trust. 
The  degree  of  knowledge  k  allows  for  the  distinction  from  unknown  and  dont  trust 
and  ranges  from  [0,1]  with  0  unknown  and  1  perfect  knowledge.  Direct  experiences 
between  agents  increase  the  value  of  k.  The  last  item,  t,  is  a  timestamp  that  allows 
for  the  fact  that  knowledge  decays  with  time. 

Recommendations  follow  the  same  format  as  the  aggregated  trusted  information 
tuple  with  the  addition  of  the  recommenders  private  key.  They  are  used  to  form  initial 
trust  opinions  and  delegation,  such  as  relying  on  third-party  assessments.  The  format 
is  shown  in  equation  2.2 
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[a,  b,l,k,t]sK: 


(2.2) 


The  trust  formation  function  T  will  return  a  predicted  trust  value  or  range  to 
base  trust  opinions  upon  and  is  used  to  predict  the  trustworthiness  of  a  trustee. 

2. 6. 1.2  Trust  Dissemination.  Trust  dissemination  uses  a  recommen¬ 
dation  exchange  protocol  to  exchange  trust  opinions.  Each  agent  carries  a  portfolio 
of  credentials  in  their  local  environment.  A  portfolio  consists  of  a  set  of  letters  rep¬ 
resenting  the  history  of  the  agent.  The  letter  is  a  tuple,  following  the  same  format 
as  recommendations.  Agent  a  will  form  a  trust  opinion  about  agent  b  by  using  the 
protocol.  Below  are  the  steps. 

1.  Agent  a  sends  agent  b  a  request  for  6’s  portfolio  of  credentials 

2.  Agent  b  replies  with  a  set  of  at  most  m  letters  of  presentation 

3.  Trust  formation  function  T  forms  a  trust  opinion  about  agent  b  based  on  the 
information  from  the  letters 

4.  Interaction  between  agents  a  and  b  may  or  may  not  take  place  depending  on 
the  resulting  trust  value  from  trust  formation  function  T 

2. 6. 1.3  Trust  Evolution.  The  evolution  of  trust  is  a  fundamental  con¬ 
cept  of  any  TMF  and  allows  for  a  continuous  self- adaptation  of  trust.  The  customizing 
functions  used  for  trust  evolution  are  the  aggregated  function  $  and  the  tacit  infor¬ 
mation  extraction  function  T  .  Trust  evolution  also  plays  a  role  in  catching  malicious 
agents. 

The  aggregation  function  $  maintains  information  about  the  trustworthiness  of 
an  agent  as  a  service  provider  and  is  used  to  update  the  perceived  trustworthiness  of 
trustee  b  when  new  direct  experiences  occur.  The  extraction  function  T  maintains 
information  about  the  trustworthiness  of  an  agent  as  a  recommender  and  is  the  sub¬ 
jective  part  of  the  TMF.  Recommendations  are  given  different  weight  values  using 
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the  extraction  function  and  are  based  on  how  much  trust  we  have  in  the  agent  the 
recommendation  came  from. 

Malicious  agents  will  send  bad  information,  spreading  fake  good  recommen¬ 
dations  and  fake  bad  recommendations.  To  help  guard  against  this,  a  boundary 
trustworthiness  value  r]  G  [-1,1]  is  dehned  for  each  agent  so  that  when  an  agents 
trustworthiness  drops  below  rj,  the  agent  becomes  suspect.  When  an  agent  becomes 
suspect,  all  recommendations  coming  from  that  agent  are  discarded. 

2.6.2  VTrust.  The  trust  relationship  in  VTrust  [16,17]  consists  of  a  vector 
with  three  components:  experience,  knowledge,  and  recommendation.  Experience  is 
the  number  of  events  two  agents  share  within  a  certain  timeframe.  Knowledge  is 
composed  of  direct  knowledge  and  indirect  knowledge.  A  recommendation  uses  a 
recommendation  value  as  its  basis  for  trust.  As  well,  neutrality  is  acceptable  in  this 
model.  Stevens  [19]  considers  the  application  of  trust  vectors  and  their  applicability 
for  Cybercraft  htness.  Their  analysis  examines  the  use  of  Cybercraft  payloads  in 
multi-agent  information  gathering  roles  where  agents  may  have  to  evaluate  informa¬ 
tion  from  other  agents.  Such  roles  cover  a  large  number  of  defense  applications  where 
network  sensing  data  are  analyzed.  Their  conclusions  show  that  a  modihed  Trust 
Vector  model  could  meet  the  needs  for  expressing  trust  decay  and  transitive  trust 
decisions  in  the  information  retrieval  context. 

The  trust  relationship  is  calculated  from  three  numeric  values  represented  as  a 
decimal  ranging  from  [-1,  1]  U  T.  A  negative  value  represents  trust-negative,  a  positive 
value  represents  trust-positive  and  a  zero  value  is  trust-neutral.  Lack  of  value  from 
insufficient  data  is  given  by  T.  This  trust  relationship  is  shown  in  equation  2.3 

=  (2.3) 
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Experience  is  the  number  of  events  two  agents  share  within  a  certain  timeframe. 
An  event  can  be  trust  positive,  trust  negative,  or  trust  neutral.  Recent  events  are 
given  more  weight. 

Knowledge  is  composed  of  direct  knowledge  and  indirect  knowledge.  Each  com¬ 
ponent  of  the  trust  model  (experience,  knowledge,  and  recommendation)  is  given  two 
values;  one  to  represent  direct  and  the  other  indirect  knowledge.  The  knowledge  pol¬ 
icy  computes  the  weight  these  values  are  given.  Knowledge  is  gathered  by  summing 
of  the  product  of  the  two  knowledge  values. 

A  recommendation  uses  a  recommendation  value  as  its  basis  for  trust.  An  agent 
uses  the  level  of  trust  ([-1,1])  to  provide  a  weighed  recommendation.  This  weight 
multiplied  with  the  former  value  will  return  the  recommendation  score  for  an  agent. 

The  VTrust  model  allows  for  two  agents  coming  up  with  different  trust  values 
from  the  same  input.  This  can  happen  when  an  agent  gives  different  weight  values 
for  each  trust  component  (experience,  knowledge,  recommendation). 

2.6.3  P2P.  In  peer-to-peer  (P2P)  systems,  peers  interact  with  unknown 
peers  without  trusted  third-parties.  In  P2P  systems  there  is  a  frequent  join  and  leave 
of  peers.  Yu,  et  ah  [22]  present  a  distributed  approach  for  P2P  systems  using  repu¬ 
tation  mechanism  for  trust.  Their  approach  uses  polling  algorithms  and  deals  with 
dishonest  or  unireliable  peers.  Peers  can  be  thought  of  as  agents  (from  the  previ¬ 
ous  models  discussed).  There  are  three  reputation  mechanisms:  ratings  generation, 
ratings  discovery,  and  ratings  aggregation.  Each  are  discussed  below. 

2. 6. 3.1  Ratings  Generation.  Ratings  generation  focuses  on  how  to 
aggregate  ratings  and  is  represented  an  interval  from  [0,1].  There  are  two  different 
types  of  ratings:  service  (reliability)  and  voting  (credibility).  Tying  these  words  into 
the  other  models,  service  is  a  service  specific  trust  opinion  and  voting  is  a  recommen¬ 
dation  trust  opinion.  A  peer  Pj  wanting  to  evaluate  the  trustworthiness  of  peer  Pj 
has  two  options:  using  direct  experience  and  recommendations.  Direct  experience  is 
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interaction  between  the  two  peers  and  recommendations  come  from  others  in  the  case 
where  Pi  and  Pj  have  no  frequent  interactions. 

The  two  different  types  of  ratings  are  local  rating  and  aggregate  rating.  Local 
rating  is  based  on  direct  interaction  and  is  generated  every  time  an  interaction  takes 
place  between  two  peers,  such  as  P*  and  Pj.  Aggregate  rating  combines  the  local 
ratings  (if  there  are  any)  with  recommendations  from  other  witnesses.  This  is  used  to 
decide  whether  peer  Pj  is  trustworthy  and  whether  peer  P,  will  propagate  the  ratings 
to  others. 

Reputation  mechanisms,  or  aggregate  ratings,  help  establish  trust  between  peers 
but  direct  interaction,  or  local  rating,  has  more  weight  in  the  decision  for  Pj  to  trust 
Pj.  In  the  case  that  Pj  and  Pj  have  not  interacted  (no  local  ratings),  if  enough 
recommendations  have  been  received,  interaction  will  occur. 

2. 6. 3. 2  Ratings  Discovery.  Ratings  discovery  uses  the  process  of  refer¬ 
rals  to  hnd  witnesses  in  an  efficient  manner.  If  a  witness  is  found,  the  response  is  sent 
in  the  reverse  path  of  the  request.  A  series  of  referrals  makes  a  referral  chain.  This 
can  be  thought  of  as  transitive  trust  or  chain  trust,  one  of  the  key  ides  for  Cybercraft. 
The  referral  chain  creates  a  trust  graph  that  is  kept  in  the  peers’  local  environment. 

2. 6. 3. 3  Ratings  Aggregation.  There  needs  to  be  a  way  to  distinguish 
between  reliable  and  deceptive  or  unreliable  peers.  Witnesses  may  not  give  true 
information  about  other  peers.  This  is  called  noisy  ratings  and  has  three  variations: 
complementary,  exaggerated  positive,  and  exaggerated  negative.  Malicious  peers  are 
either  individual  or  in  a  colluding  group.  Weighted  majority  techniques  are  used  to 
predict  the  trustworthiness  of  a  given  party.  A  peer  will  maintain  a  weight  for  the 
credibility  of  each  peer  it  requests  a  testimony  from  that  gives  an  estimate  of  how 
credible  the  peer  thinks  the  witness  is. 
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2. 7  Summary 

Our  goal  for  this  research  is  to  further  the  process  of  requirements  gathering 
using  the  tools  of  attack/defense  trees  and  use/misuse  cases.  We  discussed  in  this 
chapter  the  basic  ideas  of  trust,  along  with  the  need  for  transitive  trust  representation 
for  Cybercraft.  Then  we  discussed  the  Cybercraft  domain  and  what  that  entails 
thusfar.  Finally,  we  gave  an  overview  of  three  trust  models  that  have  the  potential 
to  be  applied  to  Cybercraft  to  give  a  value  to  trust  relationships.  The  next  chapter 
uses  the  tools  to  generate  requirements  for  Cybercraft  and  Chapter  IV  goes  over  the 
three  trust  models  in  greater  detail. 
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III.  Cybercraft  Requirements  Development 


Requirements’  gathering  is  a  daunting,  but  needed  task,  especially  for  the  ideas 
and  goals  for  Cybercraft.  As  mentioned  in  Chapter  II,  use  cases  and  attack  and 
defense  trees  are  used  to  flesh  out  some  functional  and  non-functional  requirements. 
Using  a  strategic-operational-tactical  view,  we  create  probable  Cybercraft  missions 
and/or  payloads  from  each  of  the  defense  priorities.  This  chapter  is  laid  out  as 
follows.  The  next  section  starts  the  process  for  hashing  out  requirements,  followed 
by  a  couple  of  examples  of  expanded  use  cases,  and  hnally  the  chapter  closes  with  a 
summary  of  Cybercraft  requirements. 

3. 1  Requirements  gathering 

Using  the  top  ten  defensive  priorities^,  we  compile  a  list  of  brief  use  cases  using 
a  strategic-operational-tactical  mission  level  breakdown  process.  The  defense  priori¬ 
ties  expanded  on  are:  attack  detection,  automated  network  vulnerability  mitigation, 
automated  attack  interdiction,  network  attack  damage  assessment,  automated  attack 
reporting,  and  adversary  identihcation  Use  cases  were  created  for  each  of  these 
defense  priorities  using  a  mision  level  task  breakdown  and  are  shown  in  Appendix  A. 

3.1.1  Attack  Detection.  The  hrst  defense  priority  is  attack  detection.  The 
ability  to  detect  an  attack  before,  during,  or  after,  is  crucial  to  keeping  our  networks 
secure.  USAF  networks  are  constantly  under  attack  and  our  network  defenders  must 
be  able  to  respond  quickly. 

Many  items  from  can  be  implemented  into  a  Cybercraft  mission.  Creating  logs, 
maintaining  password  policies,  monitoring  IP  addresses,  and  monitoring  ports  are  all 
good  candidates  to  become  Cybercraft  payloads  or  missions.  The  other  items  listed 
could  possibly  still  be  done  with  Cybercraft  payloads,  but  would  need  more  of  a 
breakdown  and  thought  put  into  them. 

^Air  Force  ACC  10  RAWG  2006 

^This  work  was  accomplished  with  the  help  of  Mr.  Lou  Giannelli,  Contractor,  USAF  ACC  83 
NOS  Det  3/SCN,  Lead  Network  Defender 
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With  these  use  cases,  we  can  create  numerous  attack/defense  trees.  Taking  a 
specihc  attack,  a  Code  Red  buffer  overffow,  we  create  a  defense  tree  shown  in  Figure 
3.1.  The  corresponding  attack  tree  is  shown  in  Figure  3.2.  A  Code  Red  buffer  overffow 
attack  attempts  to  connect  to  TCP  port  80,  and  once  connected,  sends  a  GET  request 
to  exploit  a  buffer  overffow 


Detect  and 
mitigate  Code  Red 
Buffer  Overflow 
attack 


_ AM. _ 

Assess  all 
connected  nodes 

- T'T - 


*• 

Sanitization  test 

Retro  APNIC 
sockets 

Figure  3.1:  A  defense  tree  for  detecting  a  Code  Red  buffer  overffow  attack. 


^retrieved  from  http:/ /www. cert.org/advisories/CA-2001-19.html 
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Figure  3.2:  An  attack  tree  for  a  Code  Red  buffer  overflow  attack. 

A  defense  tree  is  useful  in  determining  what  is  being  done  now  with  current 
tools,  processes,  or  by  human.  Currently,  traffic  validation  is  done  by  tools  and  by 
network  defenders.  There  is  no  way  to  specify  a  list  for  a  Cybercraft  to  look  for  all  the 
vulnerabilities  and  many  are  found  by  human  analysis  and  piecing  things  together. 
However,  a  Cybercraft  could  be  tasked  to  isolate  a  specihc  network  or  workstation. 
This  could  enhance  the  speed  with  which  vulnerabilities  can  be  exploited  and  the 
window  of  vulnerability  is  drastically  reduced.  Finally,  it  is  possible  for  a  Cybercraft 
to  implement  forensic  guidelines  if  they  were  scrutinized. 

Referencing  the  Code  Red  attack  tree,  there  are  certain  generalizations.  First, 
a  Cybercraft  could  dispatch  a  payload  with  AV  software  to  detect  these  types  of 
known  attacks.  As  well.  Cybercraft  could  be  more  dynamic  and  react  faster  than  AV 
software  if  it  is  always  running.  AV  software  is  supposed  to  detect  known  signatures 
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of  attacks,  but  only  when  it  is  running.  A  Cybercraft  could  be  placed  specifically  to 
detect  these  types  of  attacks  24/7. 

3.1.2  Automated  Network  Vulnerability  Mitigation.  The  second  defense  pri¬ 
ority  we  use  is  automated  network  vulnerability  mitigation.  Although  it  is  impossible 
to  automate  human  analysis,  we  can  try  to  automate  tasks  that  are  repetitive  and 
require  searching  for  specific  known  items. 

Anything  that  requires  monitoring  or  collecting  data  can  be  automated  and  are 
potential  for  Cybercraft  payloads.  A  payload  could  be  used  to  parse  data  for  specific 
items  of  “interest”.  These  items  would  have  to  be  enumerated  by  network  defender 
SME’s  (subject  matter  expert).  A  point  needs  to  be  maide  here  that  it  is  difficult  to 
automate  the  analysis  of  collected  data.  The  ability  of  human  analysis  and  interaction 
cannot  be  replaced  by  any  tool,  no  matter  what  it  boasts. 

Checking  vulnerabilities  is  a  good  area  for  Cybercraft.  A  baseline  of  param¬ 
eters  can  be  set  and  a  Cybercraft  can  notify  the  operator  when  a  change  occurrs. 
An  example  is  ensuring  current  USAF  network  policies  are  followed.  Enforcing  these 
policies  is  another  possible  Cybercraft  mission.  TCNO’s  (Time  Compliance  Network 
Order),  TCTO’s  (Time  Compliance  Technical  Order),  and  AFI’s  (Air  Force  Instruc¬ 
tions)  contain  many  of  these  policies  and  procedures  and  can  also  be  used  to  hash 
out  possible  Cybercraft  missions  and  payloads.  The  specifics  of  these  documents  are 
beyond  the  scope  of  this  thesis  and  will  be  published  as  an  area  of  future  research. 

Automated  patching  is  currently  being  done  on  USAF  networks  with  Microsoft® 
SMS  (System  Management  Server).  There  are  many  issues  with  the  implementation 
of  SMS  on  USAF  networks.  Because  of  the  varied  networks  and  programs  that  are 
mission  essential  that  need  specific  OS’s  there  is  often  a  large  exemption  list.  An 
exemption  list  includes  workstations  and  possibly  even  entire  networks  exempt  from 
the  automatic  pushing  of  patches  from  SMS.  This  exemption  list  creates  numerous 
vulnerabilities  on  the  network.  This  is  where  Cybercraft  can  come  in.  It  has  the 
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potential  to  create  new  software  or  enhance  the  old  not  so  functional  software  to 
actually  be  benehcial  and  help  ensure  security  for  the  network. 

3.1.3  Automated  Attack  Interdiction.  The  next  defense  priority  we  use 
is  automated  attack  interdiction.  We  can’t  stop  enemies  from  trying  to  attack  our 
networks,  but  we  can  work  to  interdict  and  reflect  the  attacks.  The  use  cases  created 
for  this  defense  priority  are  shown  in  Appendix  A. 3. 

If  a  device  becomes  suspect,  a  Cybercraft  will  be  able  to  isolate  the  device  in  a 
more  timely  and  efficient  manner  and  mitigate  further  devices  from  becoming  suspect 
than  current  tools  and  processes.  This  greatly  enhances  security  for  our  networks  as 
we  can  respond  at  the  speed  of  the  network  instead  of  at  human  speed.  We  envision 
Cybercraft  to  be  an  autonomous  agent,  and  thus  be  able  to  adapt  to  what  is  happening 
to  the  network. 

The  corresponding  attack  and  defense  trees  created  for  SQL  inject  attack  are 
shown  in  Figures  3.3  and  3.4  respectively.  Figure  3.3,  the  defense  tree,  shows  a 
general  sequence  of  events  for  detecting  and  mitigating  a  SQL  injection  attack.  This 
particular  case  is  mainly  done  with  analysis  from  network  defenders.  A  possible 
Cybercraft  mission  for  this  scenario  is  blocking  the  IP  segments.  A  Cybercraft  could 
accomplish  this  much  faster  than  the  human  process. 

The  attack  tree.  Figure  3.4,  steps  through  a  possible  sequence  an  attacker  could 
use  to  accomplish  a  SQL  inject  attack.  The  main  goal  if  this  attack  is  to  gain  access 
to  unauthorized  information  by  taking  advantage  of  unhltered  user  input.  To  protect 
against  these  attacks,  user  input  must  be  hltered  and  always  checked  before  blindly 
being  used  by  the  program. 

3.1.4  Network  Attack  Damage  Assessment.  The  next  defense  priority  we 
use  is  network  attack  damage  assessment.  It’s  important  to  know  the  who,  what, 
when,  where,  and  why  of  an  attack,  or  at  least  as  much  information  as  you  can.  As 
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Detect  and 
mitigate  SQL 
injection  attack 


Commercial  intei 
on  network  threats 


_ *■ 

Use  MFR  to 
generate  threat 
analysis, 
situational 
awareness, 
facilitate  blocking 
action 


Block  specific  IP 
segments 


Figure  3.3:  A  defense  tree  for  detecting  a  SQL  Inject  attack. 

the  old  saying  goes,  keep  your  enemies  closer  than  your  friends.  The  use  cases  created 
for  this  defense  priority  are  shown  in  Appendix  A. 4. 

Standard  desktop  is  a  goal  for  USAF  leaders  that  all  workstations  have  the 
same  look  and  feel  to  them.  At  first  glance,  this  would  make  security  easier,  but  there 
are  always  exceptions  and  keeping  up  with  exceptions  or  an  exemption  list  is  always 
hard  to  do.  An  exemption  list  means  manually  updating  and  patching.  Since  one  of 
the  goals  is  to  have  a  Cybercraft  installed  on  every  machine,  it  could  take  control  of 
keeping  the  computer  up-to-date. 

Currently,  the  HP  Openview  suite  of  network  management  products  is  used  to 
monitor  and  report  on  the  health  of  the  network.  We  do  not  envision  Cybercraft  to 
take  over  all  the  responsibilities  of  network  defense,  as  there  are  plenty  of  current 
soft  ware /hardware  solutions  already  in  place  (such  as  HP  Openview).  The  goal  of 
Cybercraft  is  to  supplement  these  current  tools  to  enhance  network  security  and 
ensure  we  are  protecting  ourselves  adequately. 


26 


SQL  Inject  Attack 


M _  _ A. 


Unauthorized  data 

Unauthorized  data 

extraction 

manipulation 

_ ^ _ 

Find  SQL 
vulnerability 


▼ 


Exploit 

vulnerability 


_ A _ 

Forvrard  extracted 
data 


_ A _ 

Deface  website 


Figure  3.4:  An  attack  tree  for  a  SQL  Intect  attack. 

3.1.5  Automated  Attack  Reporting.  The  next  defense  priority  we  use  is 
automated  attack  reporting.  As  well  as  knowing  the  who  and  why,  it’s  important  to 
keep  track  of  items  for  future  analysis  to  detect  patterns.  The  use  cases  created  for 
this  defense  priority  are  shown  in  Appendix  A. 5. 

Tracking  incidents  gives  us  documentation  to  compare  and  find  patterns  an 
enemy  is  using.  It  will  be  difficult  to  place  a  specific  role  to  Cybercraft  for  this 
use  case  as  this  is  mostly  a  network  defender  analysis  role.  If  there  is  anything  to 
automate,  Cybercraft  would  be  a  prime  candidate. 
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3.1.6  Adversary  Identification.  The  last  defense  priority  we  use  is  adversary 
identification.  Going  along  with  the  last  two  defense  priorities,  knowing  who  your 
enemies  are  is  extremely  important.  The  use  cases  created  for  this  defense  priority 
are  shown  in  Table  A. 6. 

These  use  cases  go  hand-in-hand  with  the  previous  section.  Along  with  anlayzing 
data  and  detecting  patterns,  hnding  out  the  source  of  the  attacks  is  very  important. 
Knowing  what  your  enemy  is  up  to  can  help  predict  a  future  attack  and  thus  help 
us  prepare  for  the  future  predicted  event  far  better  than  not  knowing  anything  in 
advance. 

3.2  Expanded  Use  Cases 

Our  hrst  scenario  deals  with  anti-virus  (AV)  software  and  ensuring  proper  con- 
hguration  on  all  workstations  on  a  network.  We  go  through  the  scenario  in  Table  3.1. 
Our  next  scenario  deals  with  the  hrewall  software  and  ensuring  proper  conhguration. 
We  go  through  the  scenario  in  Table  3.2.  These  are  only  two  examples  of  hashing 
out  details  and  hguring  out  where  we  can  use  Cybercraft  and  deploy  their  payloads. 
Ideally,  we  would  create  fully-dressed  use  cases  for  all  the  brief  use  cases  mentioned 
in  this  chapter.  This  is  an  area  of  future  work. 


3.3  Summary  of  Cybercraft  Requirements 

It  is  important  to  enumerate  requirements  of  Cybercraft.  We  need  to  know 
what  we  are  expecting  them  to  do  before  trying  to  implement  anything.  Below  is  a 
summary  of  suggestions. 

•  Ensure  secure  condition  on  the  node  using  integrity  check 

•  Supplement  SMS 


Port  monitoring 


Table  3.1:  Use  case  for  ensuring  AV  is  installed  and  up-to-date. 


Use  Case  Name 

AV 

Scope 

The  network 

Level 

Ensure  AV  software  is  installed  and  up-to-date  on  all 
machines 

Primary  Actor 

Cybercraft 

Stakeholders  and  Interests 

Network  Defenders 

Preconditions 

Network  is  operational,  up-to-date. 

Success  Guarantee 

All  machines  have  AV  software  loaded,  operational,  and 
up-to-date 

Main  Success  Scenario 

Cybercraft  platform  creates  a  payload  to  check  AV  soft¬ 
ware  on  all  machines  in  the  network,  if  all  machines  have 
operational  AV  that  is  up-to-date,  the  scenario  is  suc¬ 
cessful 

Extensions 

Cybercraft  platform  creates  a  payload  to  check  AV  soft¬ 
ware  on  all  machines  in  the  network.  Alternate  scenar¬ 
ios: 

1.  If  there  is  no  AV  software,  the  Cybercraft  platform 
dispatches  another  payload  to  install  AV  software 
on  the  machine  in  question 

2.  If  there  is  AV  software  installed,  but  not  updated, 
the  Cybercraft  platform  dispatches  another  pay- 
load  to  obtain  correct  updates  from  approved  sites 

Frequency  of  Occurrence 

Daily 

Miscellaneous 

Assumptions  are  that  the  Cybercraft  payload  and  plat¬ 
forms  are  trusted,  the  network  is  secure,  all  channels  a 
Cybercraft  uses  are  secure 

•  Network  monitoring 

•  Anomaly  detection,  send  an  alert  if  out  of  the  ordinary 

•  Flagging  an  alert  on  outbound  traffic  when  certain  conditions  are  met 

•  Enforce  TCNO/TCTO,  AFI  network  operating  procedures 

•  Parse  raw  data  transcripts  to  help  base  technicians  locate  key  elements  ^ 


^For  more  information  on  this  bullet,  refer  to  Appendix  B 
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Table  3.2:  Use  case  for  ensuring  firewall  is  installed  and  up-to-date 


Use  Case  Name 

Firewall 

Scope 

The  network 

Level 

Ensure  firewall  software  is  installed  and  up-to-date 

Primary  Actor 

Cybercraft 

Stakeholders  and  Interests 

Network  Defenders 

Preconditions 

Network  is  operational,  up-to-date, 

Snccess  Guarantee 

All  boundary  devices  have  a  hrewall  that  is  operational, 
and  up-to-date 

Main  Success  Scenario 

Cybercraft  platform  creates  a  payload  to  ensure  hrewall 
is  installed.  If  up-to-date  and  conhgured  properly,  the 
scenario  is  successful 

Extensions 

Cybercraft  platform  creates  a  payload  to  check  the  sta¬ 
tus  of  the  hrewall.  Alternate  scenarios: 

1.  If  there  is  no  hrewall,  the  Cybercraft  platform  dis¬ 
patches  another  payload  to  install  a  new  hrewall 

2.  If  there  is  a  hrewall  installed,  but  not  updated,  the 
Cybercraft  platform  dispatches  another  payload  to 
obtain  correct  updates  from  approved  sites  and  in¬ 
stall  them,  if  any 

Frequency  of  Occurrence 

Daily 

Miscellaneous 

Assumptions  are  that  the  Cybercraft  payload  and  plat¬ 
forms  are  trusted,  the  network  is  secure,  all  channels  a 
Cybercraft  uses  are  secure 
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IV.  Trust  Model  Setup 


For  Cybercraft,  we  need  a  model  to  capture  not  only  the  subjectability  of  trust, 
but  the  decision  making,  learning,  and  obeying  aspects  as  well  [7] .  The  decision 
making  process  allows  for  trust  delegation  and  when  this  should  occur.  Cybercraft 
must  know  who  is  friendly  to  be  able  to  interact  and  learn  information  from  and  be 
able  to  delegate  all  authority  and  obey  another  with  conhdence.  This  chapter  explains 
each  trust  model  in  greater  detail,  examining  the  underlying  mathematics  that  make 
the  models  work. 

4-1  hTrust 

hTrust  has  three  trust  values:  trust  formation,  trust  dissemination,  and  trust 
evolution  (reference  Chapter  II).  Stevens  states  [18]  all  Cybercraft  platforms  will  go 
through  a  formal  verihcation  but  not  all  payloads  will.  Therefore,  one  can  conclude 
that  certain  payloads  will  have  vastly  different  trust  values.  For  reference,  trust 
information  is  kept  as  a  set  of  tuples,  shown  below  in  Equation  4.1. 

[a,  6, /,  s,  c,  A:,  f]  (4.1) 

The  minimized  tuple  shown  in  Equation  4.2  is  referenced  henceforth  and  is  read 
agent  a  trusts  agent  h  at  level  I,  knowledge  k  at  time  t.  I  represents  the  level  agent  a 
has  in  agent  b  and  is  represented  as  a  range  from  [-1,1].  A;  is  the  degree  of  knowledge, 
in  other  words,  how  much  agent  a  knows  about  agent  b,  and  is  represented  as  a  range 
from  [0,1]. 


[a,b,l,k,t]  (4.2) 

Trust  formation  and  trust  dissemination  use  trust  formation  function  T.  The 
trust  evolution  phase  uses  the  two  other  functions:  the  aggregation  function  4)  and 
the  tacit  information  extraction  function  T. 
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4.1.1  Trust  Formation  Function  T.  Equation  4.3  is  the  mapping  of  Equation 
4.4.  Top  is  a  trust  prediction  (range  from  [-1,1])  based  on  one  trust  opinion  (or  tuple). 
O  is  the  set  of  all  trust  opinions  whereas  £  is  the  set  of  all  environments.  Thus,  Top  , 
shown  in  Equation  4.3  is  read  as  the  set  of  tuples  in  O  map  to  the  environment  e,  in 
the  range  [-1,1]. 

Equation  4.4  calculates  the  trust  range  using  I,  k,  and  t  from  a  tuple.  T  and 
r]  are  parameters  from  the  agents  local  environment.  T  is  the  time  interval  trust 
information  is  gathered  and  r/  is  a  boundary  value  and  agents  aren’t  trusted  if  their 
trust  opinions  fall  below  r].  Equation  4.4  is  run  on  each  tuple  to  achieve  a  trust  value 
range. 


Top:0^£^[-l,l]x[-l,l]  (4.3) 

Top[a,  6,  /,  /c,  t]e  =  [maa;(— 1, 1—  \  I  —  f  \),min{l+  \  I  —  f  |,  1)]  (4.4) 

r  1  1  f ^  T  -  {tnow  -  t)\ 

f  =  I  k*  max  I  0, - — I  (4.5) 

Another  range  is  calculated  (Equation  4.7)  from  a  set  of  m  recommendations 
received.  Equations  4.8,  4.9  and  4.10  are  used  in  Equation  4.7. 

Tree  :  piO)  ^  ^  [-1, 1]  X  [-1, 1]  (4.6) 

I  ^  ^  [howi^highl  (^*^) 


how 


\qi>v} 


^high 


J2iM^op[oi]e)^qi  I  Qi  >  y} 

ki  >  h) 


(4.8) 
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7ri(/i,  ^2)  —  ^1,  '^2{h,h)—h 


(4.9) 


qi  =  max{ri,  k[*  max  ^0,  — — )  (4.10) 

Equation  4.11  is  the  mapping  of  trust  formation  function  T.  The  set  of  all 
tuples  O  crossed  with  the  set  of  all  recommendations  p{0)  maps  to  the  environment 
e  which  produces  the  result  of  a  trust  value  range  from  [-1,1]  x  [-1,1]. 

T:Ox  piO)  ^  ^  [-1, 1]  X  [-1, 1]  (4.11) 

T[(0,  O)]^  =  hi{Top[{o)U  Trec[0]e)  (4.12) 

The  customizing  function,  hi  (Equation  4.13),  is  applied  to  the  range  produced 
from  the  function  T  and  the  final  result  is  a  prediction  of  trustworthiness  between 
two  agents  a  and  b.  The  application  chooses  a  value  from  this  range  to  use  as  a  trust 
prediction. 


hi  —  {[h,  k],  [^1,^2])  —[h2{[k,  k])—  \  h2{[li,k])  —  ^2([^i,  ^2])  1; 

(4.13) 

h2{[k,k])+  I  ^2([/l,  ^2])  -  ^2([/i,  ^2])  I] 

^2(^1)  k)  —  Wi  *  /i  -|-  W2  *  k  (4.14) 

4.1.2  Aggregation  Function  $.  The  aggregation  function  $  is  used  to  update 
an  agent’s  local  environment  when  a  new  direct  experience  occurs.  It  is  composed  of 
three  equations.  The  first  equation  (4.15),  shows  the  mapping.  A  range  from  [-1,1] 
crossed  with  the  set  of  all  recommendations  maps  to  the  environment. 
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«>:|-l,l]xp(0)^£ 


(4.15) 


Equation  4.16  is  the  first  of  two  formal  definitions  for  aggregated  function 
It  describes  the  case  where  agent  a’s  local  environment  is  updated  from  a  new  direct 
experience  with  agent  b.  Customizing  function,  (Equation  4.19),  combines  the 
three  trust  opinions  (agent  a’s  old  trust  opinion  about  agent  b,  the  trust  opinion  just 
received  about  agent  b  from  the  new  experience,  and  the  newly  updated  trust  opinion 
using  the  new  recommendations)  to  create  the  new  trust  opinion  a  will  carry  about  b 
in  its  local  environment. 

Weights  are  used  in  Equation  4.19  to  weight  the  different  values  of  1.  li  is  the 
trustworthiness  of  b  from  the  recent  interaction,  I2  is  the  opinion  previously  held  by  a 
and  /a  is  6’s  expected  trust  value  based  on  the  recent  experience.  Depending  on  which 
one  is  valued  over  the  other  will  determine  the  value  of  each  weight.  For  example,  if 
I  have  a  friend  for  many  years  whom  I  place  a  lot  of  trust  in  and  a  recent  experience 
with  her  is  not  good,  her  previous  experience  with  me  will  weigh  more  than  the  most 
recent  experience.  Tying  this  example  to  Equation  4.19,  wi  =  1,  W2  =  0,  and  = 
0  to  say  that  I  trust  past  experiences  more  than  most  recent  and  perceived  from  the 
most  recent.  But,  if  I  only  recently  met  this  same  friend,  the  most  recent  experience 
is  going  to  weigh  more  because  there  isn’t  much  past  data  to  compare  against.  Thus, 
wi  =  1,  1^2  =  1,  and  W3  =  0  which  will  change  trust  opinions  fairly  quickly  because 
we  are  taking  into  account  two  of  the  three  trust  opinions. 


<!)[/,  0]e  =  e\{[a,b,l,k,t]}  Li  {[a,b,l  ,k  ,t]}  \  o  =  lookup{b,  e)  =  [a,  b,  I,  k,  t] 

(4.16) 

A  /  /l4(/,  /,  h2(Ty.gf.[0]g))  /\  k  TTllTli^k  -\-  1)  A  t  ^now 

The  second  dehnition  of  aggregated  function  $  is  Equation  4.17.  Equation  4.17 
considers  the  case  where  a  trust  opinion  updates  soley  based  on  recommendations  and 
no  interaction  between  agents  a  and  b  occured.  This  trust  opinion  is  calculated  from 
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I  (old  trust  opinion  from  a)  and  h2(T rec[0]e) ■  k  is  not  updated  as  knowledge  is  only- 
received  from  direct  experiences 


<l>[e,  0\e  =  e  \{[a,  b,  I,  A:,  t]}  U  {[a,  b,l  ,k  ,t]}  \  o  =  lookup{b,  e)  =  [a,  b,  I,  k,  t]  A 

l'  =  h4{e,l,  h2{Trec[0]e))  A  k'  =  k  A  t  =  max{t,max{{Trtime{oi),Oi  G  O})) 


(4.17) 


(4.18) 


hiih,  hi  h) 


wi  *  h  +  W2  *  h  +  wz  *  h 

W1  +  W2  +  W3 


(4.19) 


4- 1-3  Tacit  Information  Extraction  Function  \k.  The  tacit  information  ex¬ 
traction  function  T  is  used  to  weigh  recommendations  differently  when  an  agent  must 
make  a  trust  decision  with  no  previous  direct  experiences  and  can  only  rely  on  recom¬ 
mendations.  For  example,  agent  a  might  have  a  higher  trust  value  for  agent  h  than 
agent  c  and  thus  agent  h  will  have  a  higher  weight  value  placed  on  his  recommenda¬ 
tions. 

Equation  4.15  is  the  mapping  of  tacit  information  extraction  function.  A  range 
from  [-1,1]  crossed  with  the  set  of  all  recommendations  maps  to  the  environment  and 
the  new  value  then  maps  to  the  environment. 


T  :  [-1,1]  X  p(C>)  (4.20) 

The  Trust  Management  Framework  (TMF)  maintains  a  set  of  tuples  for  each 
agent  as  a  recommender,  which  is  referred  to  as  tacit  information.  The  tacit  in¬ 
formation  extraction  function  T  updates  this  information  after  an  interaction  using 

®If  the  knowledge  component  is  able  to  be  transitively  updated  in  this  equation,  chain  trust  will 
work  for  this  model.  Reference  the  results  in  Chapter  VI 
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Equation  4.21.  The  tacit  information  tuple  is  updated  based  upon  the  perceived  trust¬ 
worthiness  of  a  recent  interaction  between  agents  a  and  h  and  the  recommendation 
about  b  from  a  recommender. 


'max 


'max 


(4.21) 


The  customizing  Function  (4.22),  creates  a  new  trust  value  based  on  the 


agents  past  trustworthiness  and  a  discrepancy.  If  the  discrepancy  of  opinions  is  lower 
than  the  tolerance  parameter,  then  trustworthiness  is  increased.  If  the  discrepancy  is 
higher,  the  trustworthiness  is  decreased.  Another  possibility  is  weighing  the  past  and 
the  new  recommendation  equally,  thus  the  last  equation  (where  n  is  not  a  factor  at 
all).  The  tolerance  parameter  decides  what  an  agent  will  select  for  a  recommender. 
The  lower  the  tolerance,  the  more  restrictive  the  agent  is  in  selecting  recommenders. 


OR  k 


(4.22) 


where  n  =  — 
k, 


min 


Table  4.1  is  an  agents  local  environment.  T  represents  the  time  interval  when 
interactions  are  observed,  tnow  is  the  current  time  the  trust  value  is  calculated,  t  is 
the  trust  value  from  the  tuple  being  used  to  calculate  the  trust  opinion  and  r;  is  a 
boundary  value  in  the  range  of  [-1,1]  that  represents  the  cutoff  of  whether  an  agent 
trusts  another  agent  below  a  certain  value. 
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Table  4.1:  Agent  a's  Local  Environment  [5]. 


Data 

Aggregated  Trust  Information 

[a,  X,  /,  k,  t] 

Tacit  Information 

[a,  X,  /,  k,  t] 

Portfolio  of  Credentials 

[x,  (2,  /,  fc,  t\sKx 

Parameters 

Time  Interval  of  Relevant  Observations 

T 

Maximum  Tolerate  Discrepancy  of  Opinions 

^max 

Single  Increment  of  Knowledge 

h  ■ 

^min 

Minimum  Trust  Level 

V 

Customizing  Functions 

Given  two  trust  ranges,  compute  a  trust 

hi 

range  (used  by  T) 

Given  a  trust  range,  compute  a  trust  opinion 

h2 

(used  by  T) 

Given  a  trust  range,  decide  whether  the  pre- 

hg 

diction  is  precise  enough  (used  by  the  recom- 

mendations  exchange  protocol) 

Given  three  trust  opinions,  compute  a  new 

h 

one  (used  by  <h) 

Given  a  trust  opinion  and  a  discrepancy. 

hg 

compute  a  new  trust  opinion  (used  by  T) 

j^.2  VTrust 

VTrust  is  composed  of  three  components:  experience,  knowledge,  and  recom¬ 
mendation.  Equation  4.23  represents  the  vector.  aE%  is  the  magnitude  of  A’s  ex¬ 
perience  about  B  in  context  c,  is  A’s  knowledge  and  is  the  affect  of  i?’s 
recommendations  to  A.  Each  of  these  three  values  fall  in  a  range  from  [-1,1]  U  T 
where  no  knowledge  is  represented  by  T. 

{A^B),=  [aE^^,aKI„^R‘b]  (4.23) 

4-2.1  Experience.  Experience  is  the  number  of  events  between  two  agents 
A  and  B  within  a  specihc  time  frame  [toRn]-  Steven’s  work  [18,19]  concluded  that 
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keeping  between  9  to  10  intervals  is  sufficient  for  Cybercraft,  depending  on  storage 
and  how  much  granularity  is  needed.  Equation  4.24  gives  the  value  for  experience  . 
Wi  is  a  non-negative  weight  and  Jj  is  the  sum  of  all  values  of  events  (trust-positive, 
trust-negative,  trust-neutral). 


aE^s  = 


En 

i=i^i 


(4.24) 


Wi  =  where  S  = -  (4.25) 

*S  2 

4-2.2  Knowledge.  The  knowledge  component  is  composed  of  two  parts: 
direct  knowledge  and  indirect  knowledge.  Equation  4.26  gives  the  knowledge  compo¬ 
nent.  d  and  r  are  in  the  range  [-1,1]  U{T},  represent  direct  and  indirect  knowledge, 
respectively,  and  Wd  +  w^  =  1. 


' 

d,  ifr  =T 


A 


]\b  — 


r,  ifd  =T 

Wd  ■  d  +  Wr  ■  r,  ifd  t^T,  r 


T,  ifd  =  r  =T 


(4.26) 


4-2.3  Recommendation.  The  recommendation  is  calculated  using  a  rec¬ 
ommendation  value  and  the  level  of  trust  the  agent  has  in  the  recommender.  The 
recommendation  value  represents  the  level  of  trust  an  agent  A  has  for  a  recommender 
agent  B.  The  equation  for  a  recommendation  is  4.27. 


_  Ej=i(^(^  ^  j)f)  ■  Vj 


(4.27) 


4/  is  a  group  of  n  recommenders  and  v{A  — >■  j)f  is  a  trust  value  from  the 
recommender  and  Vj  is  the  recommender’s  recommendation  value. 
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4-2.4  Normalization  Policy.  The  normalization  policy  takes  into  affect  the 
different  weights  a  trustor  may  assign  during  trust  evaluation.  It  is  represented  as  a 
vector  and  the  breakdown  is  displayed  in  Equation  4.28.  Trust  changes  and  decays 
with  time  and  thus  Equation  4.29  represents  the  time  affected  vector. 


{A  ^  =  WQ{A^B)t 

=  [lEe,  Wk,  IE.]  ©  UB^b,a  R%] 
=  [We-AE%,Wu-AK%,Wr-^,R%] 
=  [AE%,Ak%,^Ry\ 


(4.28) 


[aEq,a  Rr 

.vif)  vif)  vif) 


if  tn  =  0 

if  tn  A  0  and  A^s  =A  k4,  R%  =± 


'  [aE'^^A  k'A,qi  R%]  +  f3  ■  [  35353 


vft)  vjff  v{f). 

3  ’  3  ’  3  J 

if  tn  A  ^  at  least  one  of 

aEb^a  Rb  a  t 


(4.29) 


Trust  values  are  calculated  using  Equation  4.30. 


v(kl  ^  5)f  +A  KA  R% 


(4.30) 


4.3  P2P 

P2P’s  three  main  components  are:  ratings  generation,  ratings  discovery,  and 
ratings  aggregation. 

4.3.1  Ratings  Generation.  The  two  types  of  ratings  are  local  and  aggregate 
ratings.  Local  ratings  are  a  series  of  probabilistic  ratings  Sij  =  {sk,  sk, . . . ,  sk},  0  < 
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Sij  <  l,h  is  bounded  by  the  allowed  history  H.  Therefore  the  local  rating  can  be 
obtained  by  using  simple  averaging  or  exponential  averaging.  Equation  4.31  shows 
the  simple  averaging  and  Equation  4.32  shows  exponential  averaging.  Aggregate 
ratings  combine  the  local  ratings  with  those  of  any  witnesses  (recommenders) .  This 
rating  determines  trustworthiness.  The  equations  for  aggregate  ratings  are  shown  in 
Equations  4.25  and  4.34. 

Equation  4.31  adds  up  all  the  ratings  from  0  to  h  and  divides  by  the  total 
number,  h  to  get  an  average  value. 


R{P„P,) 


0  h  =  0 


(4.31) 


For  Equation  4.32,  7  determines  the  weights  given  to  the  most  recent  observa¬ 
tions.  7  ranges  from  (0  <  7  <  1)  and  the  larger  the  value  the  faster  past  observations 
are  forgotten.  The  difference  between  the  two  occurs  when  there  are  malicious  peers 
and  simple  averaging  will  give  a  value  under  the  true  value. 


7[sh  -1-  ...  -t-  (1  -  7)^*4]  h  ^  0 

0  h  =  0 


(4.32) 


Pi  uses  Equation  4.25  to  get  an  aggregate  rating  value  about  Pj.  {Wi, . . . ,  Wl} 
are  a  group  of  witnesses  for  peer  Pj  and  F(W4,  Pj)  is  the  local  rating.  Wk  is  a  weight 
assigned  to  testify  against  the  credibility  of  the  recommender  (witness).  V,  Equation 
4.33,  is  a  prediction  from  all  the  testimonies  used  to  calculate  the  aggregate  rating 
towards  peer  Pj,  Equation  4.34. 


V 


ELi^k*R{Wk,Pj)/L 

0.5  L  =  0 


(4.33) 
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r]  is  peer  Pj’s  confidence  in  its  local  rating  about  peer  Pj  where  rj  =  h/H  and  L 
is  the  number  of  witnesses  Pi  found.  When  Pj  is  new,  the  trust  rating  is  0.5  because 
it  was  found  that  it  is  more  advantageous  to  trust  new  peers  in  a  p2p  system  as  there 
aren’t  many  malicious  peers. 


np^^pJ) 


riR{Pi,  Pj)  +  (1  -  r])V  L  7^  0 
0.5  L  =  0 


(4.34) 


4-3.2  Ratings  Discovery.  Ratings  discovery  uses  a  trust  graph  to  get  referrals 
from  other  peers.  The  trust  graph  (P^,  P^,  P,  R)  is  a  directed  graph  composed  of 
referral  chains  of  P^  requesting  information  on  Pg.  P  is  a  set  of  peers  {Pi, . . . ,  P„} 
and  R  is  a  set  of  referrals  (ri, . . .  ,r„}.  An  example  trust  graph  is  shown  in  Figure 

4.1. 


Figure  4.1:  An  example  of  a  trust  graph  from  [22]. 

Po  is  trying  to  evaluate  the  trustworthiness  of  Pg.  P4  and  P7  are  witnesses  (or 
recommenders)  for  Pg.  The  requesting  peer  is  black,  queried  peers  are  gray,  and  those 
that  have  not  been  queried  are  white. 
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4.3.3  Ratings  Aggregation.  Ratings  aggregation  deals  with  incorrect  ratings, 
noisy  ratings,  that  distort  the  true  ratings  of  peers.  Equation  4.35  defines  the  three 
types  of  noisy  ratings:  complementary,  exaggerated  positive  and  exaggerated  negative. 
a  ranges  from  (0  <  a  <  1)  and  represents  the  exaggerated  coefficient,  s  is  the  true 
rating  and  s  is  the  distorted  rating.  Equation  4.36  allows  for  the  weighting  of  different 
witnesses,  depending  on  how  much  a  peer  trusts  another. 


1  —  s 

^  a  +  s  —  as 
s  —  as/(l  —  a) 


compl  ementary 
exaggerated  positive 
exaggerated  negative 


e  =  i-{i-p)  \R{Wk,p,)-s 


(4.35) 


(4.36) 
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V.  Experimental  Methodology 


The  last  chapter  walked  through  gathering  some  functional  and  non-functional 
requirements  for  Cybercraft  as  well  as  exploring  two  use  cases  used  to  examine 
potential  real-life  scenarios  Cybercraft  might  be  exposed  to.  Requirements  gathering 
is  now  applied  to  the  trust  models  to  give  a  self-defense  guarantee  and  commander’s 
trust  evaluation/expression  for  Cybercraft.  To  do  this,  we  use  three  specihc  trust 
models:  hTrust,  VTrust  and  P2P.  The  trust  models  give  a  mathematical  approach 
to  gauge  the  trustworthiness  of  interacting  entities  and  allow  for  precisely  evaluating 
security  assumptions,  attacks,  and  risks  within  the  Cybercraft  architecture.  A  math¬ 
ematical  approach  gives  understanding  for  transitive  trust  and  root  of  trust  questions 
specihc  to  Cybercraft  missions. 

The  focus  of  this  chapter  is  to  set  up  two  scenarios  for  Cybercraft  architecture 
exploration.  The  hrst  scenario  deals  with  transitive  and  root  of  trust  questions  and 
the  second  scenario  uses  the  hrst  use  case  of  updating  anti-virus  software  from  Chap¬ 
ter  III  to  analyze  and  investigate  trust  relationships  for  a  potential  real-life  scenario 
for  Cybercraft.  The  goal  of  these  scenarios  is  to  dehne  the  trust  relationships  within 
the  Cybercraft  domain  (reference  Figure  2.1).  Dehning  these  relationships  will  help 
establish  what  type  of  model  is  needed  to  give  value  to  the  trust  relationships  ex¬ 
pressed  in  Cybercraft.  For  each  scenario,  there  is  an  initial  set  of  dummy  values  to 
create  and  populate  the  trust  management  framework  for  the  trust  models.  An  area 
for  future  research  is  dehning  the  separate  components  that  make  up  the  Cybercraft 
domain  and  placing  appropriate  values  to  each.  In  the  Cybercraft  domain  model,  the 
lines  represent  a  trust  value.  This  trust  value  is  created  with  trust  models.  The  two 
scenarios  are  set  up  with  three  trust  models:  hTrust,  VTrust,  and  P2P. 

Certain  characteristics  must  be  true  in  order  for  us  to  use  a  trust  model.  A 
model  should  be  able  to  form,  maintain,  and  evolve  trust  opinions  between  entities. 
Quality  of  service  (QoS)  requirements  are  essential  as  they  decide  whether  interaction 
or  transactions  will  take  place  between  interacting  entities.  There  might  not  be  a 
globally  available  infrastrnctnre  to  interact  with  and  a  model  shonld  acconnt  for  this 
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as  well.  Interacting  entities  should  be  dynamic  and  anonymous.  Finally,  a  model 
should  incorporate  human  trust  decision,  be  subjective  and  highly  customizable. 

The  rest  of  the  chapter  is  laid  out  as  follows.  Scenario  one  is  discussed  first  in 
section  5.1,  followed  by  scenario  two  in  section  5.2. 

5.1  Scenario  One:  Transitive  Trust  Between  Entities 

The  goal  of  this  scenario  is  to  find  out  how  far  transitive  trust  can  go.  An 
example  isa— >5— i>c— >-6  which  is  read  a  trusts  b  who  trusts  c  who  trusts  d 
who  trusts  e  and  therefore  a  trusts  e.  We  want  to  see  how  far  this  trust  chain  can  go 
before  it  falls  apart.  Next  we  walk  through  each  trust  model  and  how  to  set  up  all 
the  values  and  formulas  for  this  scenario. 

There  are  two  types  of  transitive  trust:  agent  to  agent  (which  Stevens  did  [18] 
and  the  root  of  trust.  The  root  of  trust  is  the  one  we  are  most  interested  in.  We  want 
to  know  if  the  root  of  trust  in  the  Cybercraft,  or  was  it  the  OS,  transfers  to  other 
parts  of  the  system. 

5.1.1  hTrust.  For  hTrust,  we  have  to  set  up  each  agents  local  environment. 
Table  5.1  represents  the  local  environment  for  all  agents  a  -  e. 


5.1.2  VTrust.  For  VTrust,  we  only  use  the  recommendation  component  for 
scenario  one.  The  values  of  experience  and  knowledge  do  not  count  as  the  weight  to 
create  the  normalized  vectors  cancels  them  out.  We  break  down  this  scenario  into 
several  cases.  Case  one  will  use  the  initial  data  setup  shown  in  Table  5.3.  Recom¬ 
mendation  values  are  set  to  0.9  and  steady  throughout  a  chain  of  26  agents. 
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Table  5.1:  Local  Environment  in  scenario  one  -  hTrust. 


fe’s  data 

c’s  data 

d’s  data 

Aggregated  Trust  In¬ 
formation 

[b,  a,  0.3, 0.3, 4] 

[5,  c,  0.3,  0.3, 4] 

|c,(>,  0.3,0.3,41 

[c,  d,  0.3,  0.3, 4] 

[d,  c,  0.3,  0.3, 4] 

[d,  e,  0.3, 0.3, 4] 

Tacit  Information 

[6,  a,  0.4, 0.3, 4] 

[6,  c,  0.4,  0.3, 4] 

[c,  6,  0.4,  0.3, 4] 
[c,d,0.4,0.3,4] 

[d,  c,  0.4,  0.3, 4] 
[d,e,0.4,0.3,4] 

Portfolio  of  Credentals 

[a,  b,  0.3, 0.3,  A\sKa 
[c,  b,  0.3,  0.3,  A\sk^ 

[b,  c,  0.3,  0.3, 4:]sKi 
[d,  c,  0.3,  0.3,  A\sKd 

[c,  d,  0.3,  0.3,  A\sk^ 

[e,  d,  0.3, 0.3,  A\sk^ 

a’s  data 

e’s  data 

Aggregated  Trust  In¬ 
formation 

[a,  b,  0.3, 0.3, 4] 

[e,  d,  0.3,  0.3, 4] 

Tacit  Information 

[a,  5,  0.4, 0.3, 4] 

[e,  d,  0.4,  0.3, 4] 

Portfolio  of  Creden¬ 
tials 

[b,  a,  0.3, 0.3,  A\ski, 

[d,  e,  0.3,  0.3,4]sKa 

Table  5.2:  Initial  parameters  for  all  entities  in  scenario  one  -  hTrust. 


Parameters 

T 

2  minutes 

Smax 

0.8 

k  ■ 

•^min 

0.1 

7] 

0 

Customizing  Functions 

hi 

h2 

Wi  =  0,W2  =  l 

hs 

0,  if  h  <  0  and  I2  >  0 

1  otherwise 

/l4 

Wi  =  1,W2  =  l,W3  =  0 

h.5 

k  = 

ri'vl- 

k  =  U/  hk  <  k 

Table  5.4  are  the  weights  given  to  each  component  of  the  vector  [A  —>■  B)^ , 
where  We  +  Wk  +  Wr  =  1.  For  this  experiment,  we  only  consider  recommendations  as 
we  are  trying  to  gauge  how  well  VTrust  deals  with  transitive  trust  and  how  far  down 
the  chain  we  can  go. 
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Table  5.3:  Beginning  parameters  in  scenario  one,  case  one  -  VTrust. 


Trustor  Initial  Recommendation  Values 

(A  ^  R)f 

0.9 

(B  -  C)^ 

0.9 

(C  -  D)f 

0.9 

(X  ^  V)f 

0.9 

iY  -  Z}« 

0.9 

Table  5.4:  Weighting  of  vector  values,  scenario  one  -  VTrust. 


Weight  Values 

We 

0 

Wk 

0 

Wr 

1 

Stevens  thesis  [18]  proved  that  going  through  a  chain  of  5  agents  with  a  recom¬ 
mendation  value  of  0.9  for  each  link  {A  B)  results  in  a  hnal  trust  value  of  0.59049. 
In  the  experiments  we  will  test  different  values  to  better  evaluate  what  a  typical  sce¬ 
nario  for  a  Cybercraft  will  be.  Table  5.5  shows  the  walk  through  the  trust  chain  and 
resulting  values. 


Table  5.5:  Results  from  chain  of  5,  scenario  one  -  VTrust. 


Recommendation  Chain 

A^C 

0.81 

A^  D 

0.73 

A^E 

0.6561 

A^F 

0.59049 

Case  two  puts  a  little  bit  more  realistic  values  to  start.  Table  5.6  shows  the  initial 
values.  Each  agent  represents  a  part  of  the  Cybercraft  domain.  Agent  A  represents 
a  Cybercraft  platform,  agent  R  is  a  payload,  agent  C  represents  an  OS,  agent  D  the 
network,  agent  E  a  different  OS,  agent  F  a  payload  on  this  separate  machine  and 
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agent  G  is  the  locally  installed  Cybercraft  platform.  If  a  payload  goes  through  a 
formal  verification,  it  follows  that  the  platform  and  payload  will  have  complete  trust 
and  knowledge  between  each  other. 


Table  5.6:  Beginning  parameters  in  scenario  one,  case  two  -  VTrust. 


Trustor  Initial  Recommendation  Values 

(A  ^  P)f 

1.0 

(B  ^  c);' 

0.8 

{C  ^  P)f 

0.2 

(D^E)" 

0.2 

{E  P)f 

0.8 

(P  ^  G)f 

1.0 

5.1.3  P2P.  The  P2P  model  uses  certain  assumptions  on  the  system.  First, 
there  are  numerous  peers  entering  and  leaving  all  the  time  and  second,  malicious 
peers  are  rare  in  this  type  of  system.  For  the  first  scenario,  trust  chaining,  certain 
parameters  need  to  be  defined  and  set.  Table  5.7  shows  the  parameters  and  values 
given  for  this  scenario.  The  bound  of  referral  chain’s  length  (D,  the  **  value  in  the 
table)  is  what  is  being  evaluated  in  this  scenario  and  thus  is  not  set.  The  setup  is 
similar  to  the  two  previous  models.  Peer  Pi  trusts  peer  P2  at  0.9,  peer  P2  trusts  P3 
at  0.9,  and  so  on.  For  case  two,  P2P  uses  the  same  values  as  shown  in  Table  5.6. 


5.2  Scenario  Two:  Anti-virus  Update 

Scenario  two  uses  the  fully  dressed  use  case  from  Chapter  III,  section  3.2,  that 
deals  with  AV  software.  There  are  three  cases:  main  successful  scenario,  AV  is  not 
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Table  5.7:  Parameters  in  scenario  one  -  P2P. 


Symbol 

Value 

Description 

h 

1 

Number  of  latest  interactions 

H 

10 

Bound  of  allowed  history 

D 

** 

Bound  of  referral  chain’s  length 

B 

2 

Branching  factor 

a 

0.1 

Exaggeration  coefficient 

P 

0.5 

Constant 

1 

0.5 

Averaging  constant 

e 

- 

Update  factor  in  Equation  4.36 

V 

h/H 

Conhdence  about  local  ratings 

CTi 

0.5 

Threshold  of  referral  generation 

(jJi 

0.5 

Threshold  of  trust 

Table  5.8:  Beginning  values  in  scenario  one  -  P2P. 


Symbol 

Value 

Description 

R{Wi,P,) 

0.9 

Local  rating  of  witness  Wi  for  peer  Pq 

Wi 

1 

Weight  for  the  credibility  of  witness  Wi 

V 

0.1 

- 

installed,  and  AV  is  not  updated.  Each  model  uses  a  set  of  dummy  variables  to  start 
with.  An  assumption  we  use  is  payloads  cannot  talk  to  each  other.  They  must  go 
through  the  Cybercraft  platform  and  the  platform  will  talk  to  the  other  payload.  The 
general  agents  are  dehned  in  Table  5.9. 


Table  5.9:  General  agent  setup  for  all  trust  models,  scenario  two. 


Agent 

Value 

A 

Cybercraft  platform 

B 

Cybercraft  payload  check 

C 

Cybercraft  payload  update 

D 

Cybercraft  payload  install 

E 

OS 

F 

Network 

G 

AV  software  on  OS  (agent  E) 

H 

Update  place 

I 

AV  software  from  network 
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Case  one:  Cybercraft  platform  creates  a  payload,  ‘payload  check’,  to  check  if 
there  is  AV  software  loaded  on  the  machine  and,  if  so,  is  up-to-date.  The  payload  must 
interact  with  the  OS  to  inquire  about  AV  software.  The  OS  queries  its  applications 
and  responds  to  the  payload  that  yes,  there  is  indeed  AV  software  loaded.  The  payload 
then  queries  the  AV  software  to  ensure  it  is  up-to-date.  AV  software  responds  that 
everything  is  good  to  go.  Finally,  the  payload  reports  back  to  the  Cybercraft  platform 
that  AV  software  is  installed  and  up-to-date  on  this  particular  OS. 

Case  two:  Cybercraft  platform  creates  a  payload,  ‘payload  check’,  to  check  if 
there  is  AV  software  loaded  on  the  machine,  and,  if  so,  is  up-to-date.  The  payload 
interacts  with  the  OS  to  inquire  about  the  AV  software.  The  OS  queries  its  appli¬ 
cations  and  hud  there  is  no  AV  software  loaded  and  reports  these  hndings  back  to 
the  payload.  The  payload  reports  to  the  Cybercraft  platform  there  is  no  AV  software 
loaded  on  this  OS.  The  Cybercraft  platform  creates  a  new  payload,  ‘payload  install’, 
to  go  hnd  the  AV  software.  The  new  payload  must  interact  with  the  OS  and  network 
to  get  to  the  AV  software  that  is  on  the  network.  Once  the  payload  gets  the  AV  soft¬ 
ware,  it  interacts  with  the  OS  to  install  the  AV  software.  Once  installed,  the  payload 
(install)  reports  back  to  the  Cybercraft  platform  that  AV  software  is  installed.  The 
Cybercraft  platform  then  dispatches  the  previous  payload  (check)  to  ensure  the  newly 
installed  AV  software  is  up-to-date.  The  payload  interacts  with  the  OS  again  to  query 
the  AV  software.  The  AV  software  responds  to  the  payload  everything  is  up-to-date. 
The  payload  (check)  reports  to  the  Cybercraft  platform  everything  is  up-to-date  for 
the  AV  software  on  this  particular  machine  OS. 

Case  three:  Cybercraft  platform  creates  a  payload,  ‘payload  check’,  to  check  if 
there  is  AV  software  loaded  on  the  machine,  and,  if  so,  is  up-to-date.  The  payload 
interacts  with  the  OS  to  inquire  about  the  AV  software.  The  OS  queries  its  applica¬ 
tions  and  responds  to  the  payload  there  is  AV  software  loaded.  The  payload  queries 
the  AV  software  to  ensure  it  is  up-to-date.  The  AV  software  responds  that  no,  it  is 
not  up-to-date.  The  payload  then  reports  to  the  Cybercraft  platform  that  the  AV 
software  loaded  on  the  OS  is  not  up-to-date.  The  Cybercraft  platform  creates  a  new 
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payload,  ‘payload  update’,  to  update  the  AV  software.  The  new  payload  must  inter¬ 
act  with  the  OS  and  network  to  get  to  the  AV  software  update  on  the  network.  Once 
the  payload  gets  the  AV  update  ,  it  interacts  with  the  OS  to  install  the  update.  Once 
the  update  is  installed,  the  payload  (update)  reports  back  to  the  Cybercraft  platform 
that  AV  software  is  up-to-date. 

Certain  assumptions  were  made  for  this  scenario.  The  hrst  is  that  all  parts 
of  the  system  are  secure  and  trustworthy  (not  malicious).  Network,  OS,  Cybercraft 
platform  and  agent.  Next,  all  trust  interactions  result  in  a  good  trust  value.  Lastly, 
the  goal  of  the  scenario  is  to  evaluate  the  resulting  values  of  trust  between  each  of 
the  three  models. 

5.2.1  hTrust.  For  hTrust,  there  is  an  initial  set  of  tuples  for  the  agents  that 
know  about  each  other.  Walking  through  the  cases,  we  hgure  out  where  all  those 
equations  £t  in.  Each  agent  wanting  to  talk  to  another  agent  it  does  not  know  about 
must  run  the  recommendation  protocol  (reference  Chapter  II,  Section  2. 6. 1.2),  which 
uses  the  trust  formation  function  T  (Equation  4.12)  to  create  a  trust  prediction.  For 
the  sake  of  these  cases,  we  always  choose  the  middle  value.  After  the  interaction, 
tuples  are  exchanged  between  the  two  agents  and  each  runs  the  aggregation  function 
$  (reference  Equation  4.16)  to  update  their  tuples  in  their  local  environment,  if  any. 
Then,  the  requesting  agent,  the  trustor,  will  run  the  tacit  information  extraction 
function  T  (reference  Equation  4.21)  to  update  the  recommendation  value  of  the 
agent  that  recommended  the  trustee. 

The  parameters  are  similar  as  in  scenario  one,  except  a  few  minor  changes, 
shown  in  Table  5.10.  The  weights  for  the  customizing  function,  h2  are  both  0.5  as 
we  want  to  consider  trust  reflexivity  and  trust  transitivity.  Everything  else  is  left  the 
same  as  from  scenario  one.  The  next  sections  go  through  the  data  setup  for  each  case 
in  scenario  two  for  hTrust. 

The  trust  values  were  chosen  for  each  agent  as  close  to  what  a  real  scenario 
would  look  like.  For  example,  the  Cybercraft  platform,  agent  a,  will  trust  a  payload 
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explicitly  if  it  has  been  formally  verified  and  that  platform  created  it.  The  Cybercraft 
payload  check  (agent  b)  has  a  trust  level  of  1  and  knowledge  1,  but  the  Cybercraft 
payloads  update  and  install  (c  and  d)  have  a  trust  level  of  0.5  (knowledge  still  1  because 
the  Cybercraft  platform  created  them)  because  these  payloads  will  be  interacting  with 
other  parts  of  the  system  and  therefore  will  have  a  lower  initial  trust  value.  The  OS 
(agent  e)  will  have  full  trust  and  knowledge  of  items  currently  installed  on  it,  such  as 
the  AV  software  (agent  g).  The  OS  does  not  directly  correspond  with  the  Cybercraft 
platform  (agent  a),  and  therefore  does  not  have  full  trust  in  it,  as  well  as  the  network. 

Table  5.10:  Initial  parameters  for  all  entities  in  scenario  two. 


Parameters 

T 

2  minutes 

^max 

0.8 

h  ■ 

^min 

0.1 

V 

0 

Customizing  Functions 

hi 

i'i,Q 

h2 

Wi  =  0.5,  W2  =  0.5 

hz 

0,  if  li  <  0  and  0  >  0 

1  otherwise 

hi 

hs 

Wi  =  1,W2  =  l,W3  =  0 

h  =  dk  >  k 

j  2-6C 

k  =  U/  */  dh  <  h 

5. 2. 1.1  Case  One.  Case  one  uses  agents  a,b,e  and  g.  Time  starts  at 
f  =  10  at  the  beginning  of  the  scenario  to  account  for  the  generation  of  trust  through 
time.  Table  5.11  shows  the  local  environment  of  all  the  agents. 


5.2. 1.2  Case  Two.  Case  two  uses  agents  a,  6,  d,  e,  /  and  i.  Time  starts 
at  f  =  10  at  the  beginning  of  the  scenario  to  account  for  the  generation  of  trust 
through  time.  Table  5.12  displays  the  agents’  local  environment. 
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Table  5.11:  Local  environment  for  scenario  two,  case  one  -  hTrnst. 


a’s  data 

e’s  data 

Aggregated  Trnst  Information 

[a,  5, 1,1, 10] 

[a,  6,0.7,0.5,10] 

[e,  a,  0.8,  0.8, 10] 

[e,  S',  1,1,10] 

Tacit  Information 

[a,  5,  0.8, 1, 10] 

[a,  6,  0.5,  0.5, 10] 

[e,  a,  0.8,  0.8, 10] 

[6,5-,  1,1,10] 

Portfolio  of  Credentials 

[6,  a,  1, 1, 10] 

[e,  a,  0.8,  0.8,  lO]^/^^ 

[a,  6,  0.7,  0.5, 10]5K„ 

1, 1, 10]5i6g 

5’s  data 

g^s  data 

Aggregated  Trnst  Information 

[5,  a,  1,1, 10] 

^,6,1,1,10] 

Tacit  Information 

[5,  a,  1,1, 10] 

^,6,1,1,10] 

Portfolio  of  Credentials 

[a,  b,  1, 1,  lojsi^-^ 

^1 9^  1, 1, 10]5j^g 

Table  5.12:  Local  environment  for  scenario  two,  case  two  -  hTrnst. 


a’s  data 

e’s  data 

/’s  data 

Aggregated  Trnst 
Information 

[a,  6, 1,1, 10] 

[e,  a,  0.8,  0.8, 10] 

[/,  6,  0.8,  0.8, 10] 

[a,  d,  0.5, 1,10] 

[a,  6, 0.75,  0.5, 10] 

[e,/,  0.8,  0.8, 10] 

[/,z,  0.8,  0.8, 10] 

Tacit  Information 

[a,  5,  0.8, 1,10] 

[e,  a,  0.8,  0.8, 10] 

[/,  6,  0.8,  0.8, 10] 

[a,  d,  0.5, 1,10] 

[a,  6, 0.5,  0.5, 10] 

[e,/,  0.8,  0.8, 10] 

[/,z,  0.8,  0.8, 10] 

Portfolio  of  Cre¬ 
dentials 

[6,  a,  1, 1,  lO]^^^ 

[a,  6,  0.7,  0.5, 10]5x, 

[e,/,0.8,0.8,10]5i^. 

[(i,  Gt,  1,  1,  10] 

[e,  a,  0.8,  0.8,  lOj^i^^ 

[/,e,0.8,0.8,10]5x, 

[z,/,0.8,0.8,10]5i^. 

5’s  data 

d’s  data 

i’s  data 

Aggregated  Trnst 
Information 

[6,  a,  1,1, 10] 

[d,  a,  1,1, 10] 

[z,/,  0.8,  0.8, 10] 

Tacit  Information 

[5,  a,  1,1, 10] 

[d,  a,  1, 1, 10] 

[z,/,  0.8,  0.8, 10] 

Portfolio  of  Cre¬ 
dentials 

[a,  b,  1, 1,  lojsxa 

[ci,  (i,  0.5, 1,  lOj^'ji'^ 

[/,z,0.8,0.8,10]5i^, 

5. 2. 1.3  Case  Three.  Case  three  nses  agents  a,b,c,e,  f,  g  and  h.  Time 
starts  at  t  =  10  at  the  beginning  of  the  scenario  to  acconnt  for  the  generation  of  trnst 
throngh  time.  Table  5.13  is  the  local  environment  for  the  agents. 
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Table  5.13:  Local  environment  for  scenario  two,  case  three  -  hTrust. 


a’s  data 

e’s  data 

/’s  data 

Aggregated  Trust 
Information 

[a,  6, 1,1, 10] 

[e,  a,  0.8,  0.8, 10] 

[/,  6,  0.8,  0.8, 10] 

[a,c,  1, 1, 10] 

[a,  6,0.7,0.5,10] 

[e,/,  0.8,  0.8, 10] 

[e,^,  1,1,10] 

[/,h,  0.8,  0.8, 10] 

Tacit  Information 

[a,  5,  0.8, 1,10] 

[e,  a,  0.8,  0.8, 10] 

[/,  6,  0.8,  0.8, 10] 

[a,  c,  0.9, 1, 10] 

[a,  6, 0.5,  0.5, 10] 

[e,/,  0.8,  0.8, 10] 

[e,^,  1,1,10] 

[/,h,  0.8,  0.8, 10] 

Portfolio  of  Cre¬ 
dentials 

[6,  a,  1, 1,  lO]^^^ 

[a,  6,  0.7,  0.5, 10]5x, 

[e,/,0.8,0.8,10]5i^. 

[c,a,  1, 1, 10]sK, 

[e,  a,  0.8,  0.8, 10]5i<-^ 

[/,e,0.8,0.8,10]5x^ 

[s',  e,  1, 1, 10]5A'g 

[h,/,0.8,0.8,10]5i^. 

5’s  data 

c’s  data 

g^s  data 

Aggregated  Trust 
Information 

[5,  a,  1,1, 10] 

[c,a,  1, 1, 10] 

[fif,  6,  1,1,10] 

Tacit  Information 

[b,  a,  1, 1, 10] 

[c,  a,  1, 1, 10] 

[^,6,1,1,10] 

Portfolio  of  Cre¬ 
dentials 

[a,  5, 1, 1,  lojsxa 

[ci,  c,  1, 1, 

[^1  9"} 

h’s  data 

Aggregated  Trust 
Information 

[h,/,  0.8,  0.8, 10] 

Tacit  Information 

[h,/,  0.8,  0.8, 10] 

Portfolio  of  Cre¬ 
dentials 

[/,  h,0.8,0.8,10]sK, 

5.2.2  VTrust.  VTrust  differs  from  hTrust  in  that  the  trust  vectors  are  not 
updated  after  each  interaction,  but  from  a  series  of  events.  The  experience  component 
is  computed  by  taking  a  series  of  events,  broken  into  time  intervals,  and  giving  a  weight 
value  to  each  set.  The  time  interval  set  for  this  case  is  ti  =  2.  represents  one 

interval.  There  was  no  initial  setting  to  the  vectors  for  this  scenario.  Parameters  for 
case  two  are  shown  in  table  5.14. 
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Table  5.14:  Parameters  for  VTrust,  scenario  two. 


Parameters 

dkw 

Direct  knowledge  weight 

Indirect  knowledge  weight 

Ew 

Experience  component  weight 

Knowledge  component  weight 

Ryj 

Recommendation  component  weight 

d 

Direct  knowledge  valne 

r 

Indirect  knowledge  value 

5.2.2. 1  Case  One.  Case  one  nses  agents  A,B,E  and  G.  Time  starts 
at  t  =  0  at  the  beginning  of  the  scenario  to  acconnt  for  the  generation  of  trnst  throngh 
time.  Table  5.15  is  the  local  environment  for  the  agents. 


Table  5.15:  Local  environment  in  scenario  two,  case  one  -  VTrnst. 


A’s  environment 

R’s  environment 

A 

-  B 

B  - 

-A 

B- 

-  E 

B  - 

-G 

dku, 

1 

dkw 

1 

dkw 

0.7 

dkw 

0.7 

tk-w 

0 

tkyj 

0 

tkyj 

0.3 

tkyj 

0.3 

Eiu 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.5 

Kw 

0.5 

Kw 

0.3 

Kw 

0.3 

Rw 

0 

Rw 

0 

Rw 

0.2 

Rw 

0.2 

d 

1 

d 

0.3 

d 

0.3 

d 

1 

r 

0 

r 

0 

r 

0.7 

r 

0.6 

E’s  environment 

G’s  environmen 

E 

-  B 

E- 

-G 

G- 

-  B 

G- 

-  E 

dkw 

0.7 

dkw 

1 

dkw 

0.7 

dkw 

1 

tkyj 

0.3 

%kyj 

0 

%kyj 

0.3 

%kyj 

0 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Kw 

0.3 

Kw 

0.5 

Kw 

0.3 

Kw 

0.5 

Rw 

0.2 

Rw 

0 

Rw 

0.2 

Rw 

0 

d 

0.3 

d 

1 

d 

0.3 

d 

1 

r 

0.7 

r 

0 

r 

0.7 

r 

0 
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5. 2. 2. 2  Case  Two.  Case  two  uses  agents  A,  B,  D,  E,  F  and  I.  Time 
starts  at  t  =  0  at  the  beginning  of  the  scenario  to  account  for  the  generation  of  trust 
through  time.  Table  5.16  is  the  agents’  local  environment. 


5. 2. 2. 3  Case  Three.  Case  three  uses  agents  A,  B,C,  E,  F,G  and  F[. 
Time  starts  at  t  =  0  at  the  beginning  of  the  scenario  to  account  for  the  generation  of 
trust  through  time.  Table  5.17  is  the  local  environment  of  the  agents. 


Table  5.17:  Local  environment  in  scenario  two,  case  three  -  VTrust. 


C’s  environment 

C- 

-A 

C- 

-  E 

C- 

-  F 

C- 

-  H 

C- 

-G 

dkw 

1 

dkw 

0.7 

dkw 

0.7 

dkw 

0.7 

dkw 

0.7 

0 

ikyj 

0.3 

tkyj 

0.3 

tkyj 

0.3 

%k^ 

0.3 

Eu, 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.5 

0.3 

Kw 

0.3 

Kw 

0.3 

Kw 

0.3 

Ru) 

0 

Rw 

0.2 

Rw 

0.2 

Rw 

0.2 

Rw 

0.2 

d 

1 

d 

0.3 

d 

0.3 

d 

0.3 

d 

0.3 

r 

0 

r 

0.7 

r 

0.5 

r 

0.6 

r 

0.6 

A’s  environment 

B's  environment 

A- 

-  B 

A- 

-C 

B  - 

-E 

B  - 

-A 

B  - 

-G 

dkw 

1 

dkyj 

1 

dkw 

0.7 

dkw 

1 

dkw 

0.7 

tkyj 

0 

0 

tkyj 

0.3 

tkyj 

0 

'ikn) 

0.3 

Eyo 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.5 

0.5 

Kw 

0.3 

Kw 

0.5 

Kw 

0.3 

Rw 

0 

Rw 

0 

Rw 

0.2 

Rw 

0 

Rw 

0.2 

continued  on  next  page 
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Table  5.16:  Local  environment  in  scenario  two,  case  two  -  VTrust. 


A’s  environment 

BA  environment 

A- 

-  B 

A- 

-  D 

B  - 

-  E 

B  - 

-A 

dkw 

1 

dkw 

1 

dkw 

0.7 

dkw 

1 

tkyj 

0 

%kyj 

0 

%kyj 

0.3 

%kyj 

0 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.5 

Kw 

0.5 

Kw 

0.3 

Kw 

0.5 

Rw 

0 

Rw 

0 

Rw 

0.2 

Rw 

0 

d 

1 

d 

1 

d 

0.3 

d 

1 

r 

0 

r 

0 

r 

0.7 

r 

0 

DA  environmen 

D  - 

-  A 

D  - 

-  E 

D  - 

-  E 

D 

-  I 

dkw 

1 

dkw 

0.7 

dkw 

0.7 

dkw 

0.7 

tk-w 

0 

%kyj 

0.3 

tk-u) 

0.3 

tkyj 

0.3 

Eui 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.5 

Kw 

0.3 

Kw 

0.3 

Kw 

0.3 

Rw 

0 

Rw 

0.2 

Rw 

0.2 

Rw 

0.2 

d 

1 

d 

0.3 

d 

0.3 

d 

0.3 

r 

0 

r 

0.7 

r 

0.5 

r 

0.6 

EA  environmen 

EA  environmen 

E- 

-  B 

E- 

-  D 

E- 

-  D 

E  - 

-I 

dkw 

0.7 

dkw 

0.7 

dkw 

0.7 

dkw 

1 

tkyj 

0.3 

ikyj 

0.3 

tkyj 

0.3 

tkyj 

0 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Kw 

0.3 

Kw 

0.3 

Kw 

0.3 

Kw 

0.5 

Rw 

0.2 

Rw 

0.2 

Rw 

0.2 

Rw 

0 

d 

0.3 

d 

0.3 

d 

0.3 

d 

1 

r 

0.7 

r 

0.7 

r 

0.8 

r 

0 

J’s  environment 

I- 

-D 

I  - 

-E 

dkw 

0.7 

dkw 

1 

tkyj 

0.3 

%kyj 

0 

Ew 

0.5 

Ew 

0.5 

Kw 

0.3 

Kw 

0.5 

Rw 

0.2 

Rw 

0 

d 

0.3 

d 

1 

r 

0.8 

r 

0 

continued  from  previous  page 


1 

d 

1 

d 

0.3 

d 

1 

d 

0.3 


continued  on  next  page 
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continued  from  previous  page 

r 

0 

r 

0 

r 

0.7 

r 

0 

r 

0.6 

77 ’s  environment 

F’s  environment 

H -C 

H  -E 

E-E 

E-H 

E-G 

dkw 

0.7 

dkyj 

1 

dkw 

01 

dkw 

1 

dkw 

0.7 

0.3 

tkw 

0 

tkw 

0 

tkw 

0 

tkw 

0.3 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.3 

Kw 

0.5 

Kw 

0.5 

Kw 

0.5 

Kw 

0.3 

Rw 

0.2 

Rw 

0 

Rw 

0 

Rw 

0 

Rw 

0.2 

d 

0.3 

d 

1 

d 

1 

d 

1 

d 

0.3 

r 

0.8 

r 

0 

r 

0 

r 

0 

r 

0.8 

£”s  environment 

E-B 

E-G 

E-G 

E-E 

dkw 

0.7 

dkw 

1 

dkw 

0.7 

dkw 

1 

tkyp 

0.3 

tkw 

0 

tkw 

0.3 

tkw 

0 

Eu, 

0.5 

Ew 

0.5 

Ew 

0.5 

Ew 

0.5 

0.3 

Kw 

0.5 

Kw 

0.3 

Kw 

0.5 

Rw 

0.2 

Rw 

0 

Rw 

0.2 

Rw 

0 

d 

0.3 

d 

1 

d 

0.3 

d 

1 

r 

0.7 

r 

1 

r 

0.7 

r 

1 

G’s  environment 

G-E 

G-B 

G-G 

dkw 

01 

dkw 

0.7 

dkw 

0.7 

tkw 

0 

tkw 

0.3 

tkw 

0.3 

Eu, 

0.5 

Ew 

0.5 

Ew 

0.5 

0.5 

Kw 

0.3 

Kw 

0.3 

continued  on  next  page 
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continued  from  previous  page 

Rnj 

0 

Rw 

0.2 

Rw 

0.2 

d 

1 

d 

0.3 

d 

0.3 

r 

0 

r 

0.7 

r 

0.7 

5.2.3  P2P.  The  parameters  are  very  similar  to  those  of  scenario  one.  Table 
5.18  shows  the  parameters  and  values  given  for  this  scenario. 


Table  5.18:  Parameters  for  the  P2P  model,  scenario  one. 


Symbol 

Value 

Description 

/9 

0.5 

Constant 

e 

- 

Update  factor  in  Equation  4.36 

V 

.5 

Conhdence  about  local  ratings 

5.2.3. 1  Case  One.  Case  one  uses  agents  Pa,  Pb,  Pe  and  Pg.  Time  starts 
at  t  =  0  at  the  beginning  of  the  scenario  to  account  for  the  generation  of  trust  through 
time.  The  only  initial  values  of  this  scenario  are  the  fact  that  Pa  and  Pb,  and  Pe  and 
Pg  have  a  direct  knowledge  of  1  for  each  other. 

5. 2. 3. 2  Case  Two.  Case  two  uses  agents  Pa,  Pb,  Pd,  Pe,  Pf,  and  Pj. 
Time  starts  at  t  =  0  at  the  beginning  of  the  scenario  to  account  for  the  generation  of 
trust  through  time.  The  only  initial  values  of  this  scenario  are  the  fact  that  Pa  and 
Pb,  Pa  and  Pd,  Pe  and  Pj,  and  Pg  and  Pj  have  a  direct  knowledge  of  1  for  each  other. 

5. 2. 3. 3  Case  Three.  Case  three  uses  peers  P^,  P^,  Pc,  Pe,  P/,  Pg  and  P^. 
Time  starts  at  t  =  0  at  the  beginning  of  the  scenario  to  account  for  the  generation  of 
trust  through  time.  The  only  initial  values  of  this  scenario  are  the  fact  that  Pa  and 
Pb,  Pa  and  Pc,  Pe  and  P/,  Pf  and  Ph,  and  Pg  and  Pg  have  a  direct  knowledge  of  1  for 
each  other. 
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VI.  Analysis  and  Results 


This  chapter  covers  the  results  of  the  scenarios  from  each  of  the  three  models. 

Scenario  one  examined  two  variations  of  transitive  trust:  agent  to  agent  and 
the  root  of  trust.  Scenaro  two  used  the  AV  use  case  from  chapter  III,  section  3.2. 
Scenario  one  results  are  discussed  in  section  6.1  and  scenario  two  results  are  discussed 
in  section  6.2. 

6.1  Scenario  One:  Transitive  Trust 

6.1.1  Analysis.  The  two  types  of  transitive  trust  analyzed  are  agent  to  agent 
and  the  root  of  trust.  Stevens  [18]  work  focused  mainly  on  transitive  trust  between 
agents. 

6.1.2  Results.  We  breakout  the  results  of  scenario  one  based  on  our  three 
candidate  trust  models.  We  discuss  hTrust  first,  then  VTrust,  and  conclude  with  P2P 
analysis. 


6. 1.2.1  hTrust.  The  results  show  that  the  chain  trust  from  a  ^  b 

c  ^  d  ^  e  falls  apart  after  c.  hTrust  has  no  transitivity  of  trust.  Agent  a  receives 
a  recommendation  from  b  about  c  and  a’s  knowledge  of  c  is  set  to  0.  To  continue 
with  the  chain,  there  must  be  some  sort  of  interaction  between  a  and  c  for  a  to  have 
knowledge  about  c  as  a  recommender.  A  way  for  things  to  work  would  be  for  the 
knowledge  component  to  be  transitive  just  as  the  trust  value  is.  Case  two  was  not 
evaluated  because  of  the  results  from  case  one. 

6. 1.2. 2  VTrust.  For  case  one,  setting  all  values  to  0.9  for  recommen¬ 
dations,  agent’s  A  —  Z  create  a  chain  that,  with  the  range  from  [0,1],  still  does  not  go 
to  0.  This  is  an  unrealistic  scenario  as  there  is  a  very  small  chance  there  will  be  a  set 
of  agents  that  have  a  chain  with  a  recommendation  value  of  0.9  for  every  chain.  The 
results  are  shown  in  Figure  6.1  and  show  that  even  through  26  agents,  the  trust  value 
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is  not  negative  and  not  quite  0  (0.0646).  There  is  a  0.75  difference  in  the  beginning 
value  and  last  trust  recommendation. 

VTmst  Chain  Trust  Results 

1.0000 
0.9000 
0.8000 
0.7000 

3  0.6000 

n 

t  0.5000 

tf) 

^  0.4000 
0.3000 
0.2000 
0.1000 
0.0000 


- 1  I  I - 1  I  I  I  I  I  I  I  II - 1  I  I  I  I - 1  I  I  I  I - 

a-c  a-d  a-e  a-f  a-g  a-h  a-i  a-j  a-k  a-l  a-m  a-n  a-o  a-p  a-q  a-r  a-s  a-t  a-u  a-v  a-w  a-x  a-y  a-z 

Agent 


Figure  6.1:  Results  for  trust  chaining  agents  A  —  Z  -  VTrust. 

The  second  case  uses  more  realistic  values  mapping  to  a  possible  Cybercraft 
domain  and  trys  to  more  accurately  predict  the  environment  a  Cybercraft  will  be 
in.  The  results,  from  Figure  6.2,  show  trust  degrades  much  faster.  It  only  takes 
two  recommendations  before  the  value  drops  0.6  points,  which  is  very  significant, 
especially  within  the  range  G  [0,1]. 

6. 1.2. 3  P2P.  The  P2P  model  shows  that  there  is  a  high  limit  (un¬ 
known  as  of  yet)  for  trust  chaining.  Because  of  the  way  a  P2P  system  is  setup,  peers 
trust  until  proven  otherwise.  Therefore  the  trust  chain  resulting  from  peer  P*  attempt¬ 
ing  to  interact  with  peer  Pj,  can  be  very  long.  Pj  uses  the  witness(es)  that  attest  to 
Pj.  The  chain  is  used  to  find  these  witnesses  and  nothing  more.  The  witnesses’  (W4) 
local  rating  for  Pj  is  used,  along  with  a  weighting  of  the  trust  Pi  has  in  Wk  (set  to 
1  if  Pj  has  never  interacted  with  Wk  before)  to  get  a  predicted  trust  value.  If  this 
value  is  above  a  certain  threshold,  u,  then  peer  Pi  will  interact  with  Pj  and  update 
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Figure  6.2:  Results  for  trust  chaining  agents  A  —  G  -  VTrust. 

its  information.  For  our  first  scenario,  we  used  a  value  of  0.9.  This  yielded  a  hnal 
trust  value  of  0.81,  with  a  threshold  of  0.5.  Therefore,  peer  P*  will  interact  with  peer 
Pj.  A  summary  of  the  results  is  shown  in  Table  6.1.  Changing  the  beginning  value 
will  not  affect  the  resulting  trust  value  in  a  signihcant  way 


Table  6.1:  Results  from  the  P2P  model,  scenario  one,  case  one. 


Recommendation  Chain  Results 

Pi^Pe 

0.81 

Case  two  uses  the  same  values  as  VTrust  in  scenario  one,  case  two.  Peer  Pi 
wishes  to  interact  with  peer  P7  and  the  resulting  trust  value  is  0.05.  The  reson  for 
this  is  because  of  the  value  Pe  — >■  P7  =  0.1.  Thus,  peer  Pi  uses  that  value  as  a  starting 
point.  The  results  are  shown  in  Table  6.2. 
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Table  6.2:  Results  from  the  P2P  model,  scenario  one,  case  two. 


Recommendation  Chain  Results 

Pi^Pe 

0.05 

6.2  Scenario  Two:  Anti-virus  Update 

6.2.1  Analysis.  The  goal  for  scenario  two  was  to  implement  one  of  the 
fully-dressed  use  cases  from  Chapter  III,  specihcally  the  one  dealing  with  AV  update. 

6.2.2  Results.  The  results  for  case  one,  two  and  three  are  shown  in  Figures 
6.3,  6.4  and  6.5.  The  graph  shows  the  agent  interactions  on  the  x-axis.  It  is  read 
agent  a  trusts  agent  b  {a  —  b).  The  y-axis  is  the  resulting  trust  value  at  the  end  of 
the  scenario.  The  results  are  similar  through  all  three  cases.  The  numbers  are  very 
similar  between  each  model  and  agent.  The  difference  comes  in  where  hTrust  has  a 
1  value  throughout  the  entire  scenario.  hTrust  therefore  does  not  allow  for  the  factor 
of  time  decay.  The  other  two  models  factored  that  in  and  thus  their  numbers  are 
lower  for  those  agent  trust  relationships.  Another  observation  is  hTrust  generally  has 
a  lower  trust  value  for  certain  agents  (ones  that  didn’t  start  with  a  1  value)  than  the 
other  two  models  VTrust  and  P2P. 

For  hTrust,  time  started  at  t  =  10,  increased  in  increments  of  2,  and  ended  at  t 
=  16.  The  interactions  for  case  one,  in  order,  were  a  — 6,  b  —  e,  e  —  g,  g  —  e,  e  —  b,  b  —  a. 
Agents  b  —  g  and  e  —  g  did  not  exchange  any  sort  of  recommendations  and  thus  their 
tacit  information  tuples  were  not  updated.  The  results  from  show  that  with  somewhat 
realistic  values,  trust  will  not  degrade  too  fast  to  a  point  where  the  model  becomes 
useless.  A  case  for  future  work  is  to  run  scenarios  adjusting  all  the  parameters  (such 
as  the  customizing  functions  hi  —  6^,7],  etc.).  For  case  two,  time  started  at  t  =  10, 
increased  in  increments  of  2,  and  ended  at  t  =  22.  The  interactions,  in  order,  were 
a—b,b—e,  e—b,  b—a,  a—d,  d—e,  d—f,  d—i,  i—d,  d—e,  d—a,  a—b,  b—i,  i—b,  b—a. 
Agents  e  —  /  and  f  —  i  did  not  exchange  any  sort  of  recommendations  and  thus  their 
tacit  information  tuples  were  not  updated.  For  case  three  time  started  at  t  =  10, 
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increased  in  increments  of  2,  and  ended  at  t  =  20.  The  interactions,  in  order,  were 
a  —  b,  b  —  e,  e  —  g,  e  —  b,  b  —  a,  a  —  c,  c  —  e,  c  —  f,  c  —  h,  h  —  c,  c  —  e,  c  —  a,  a  —  c. 
Agents  e  —  g  and  f  —  h  did  not  exchange  any  sort  of  recommendations  and  thus  their 
tacit  information  tuples  were  not  updated. 

VTrust  calculates  the  value  of  trust  over  a  period  of  time  as  opposed  to  after 
each  interaction  (such  as  hTrust).  For  this  scenario,  all  interactions  were  recorded, 
then  a  final  trust  value  was  created.  The  P2P  model  calcutes  trust  values  after  each 
interaction. 

Scenario  Two,  Case  One 


1.00  -r 

0.90  - 
0.80  - 


a-b  b-a  b-e  e-b  e-g  g-e  b-g  g-b 

Agents 


Figure  6.3:  Results  for  Scenario  Two,  Case  One. 


6. 3  Reference  Framework 

A  proponent  of  hTrust  is  the  various  parameters  and  customizing  functions. 
These  elements  allow  for  a  better  evaluation  of  trust.  The  problem  with  hTrust  is  the 
model  breaks  down  after  only  one  recommendation.  hTrust  does  not  in  its  current 
state  allow  for  the  degredation  of  trust  over  time.  Cybercraft  are  going  to  need  to  have 
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Figure  6.4:  Results  for  Scenario  Two,  Case  Two. 


Scenario  Two,  Case  Three 


n) 

> 


Agents 


□  hTmst 
■  VTrust 

□  P2P 


Figure  6.5:  Results  for  Scenario  Two,  Case  Three. 
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numerous  chains.  VTrust  allows  for  trust  chaining  but  does  not  have  a  framework  to 
implement  the  model  and  seems  to  be  a  piecemeal  of  components  to  create  a  value. 
P2P  allows  for  a  long  chain  of  trust  but  with  the  assumption  to  trust  a  peer  until  it  is 
proven  malicious  will  not  work  for  Cybercraft.  The  opposite  is  true,  Cybercraft  must 
be  less  trusting  of  new  peers.  Another  thought  is  P2P  only  allows  for  an  interval  of 
[0,1].  This  is  not  adequate  to  represent  a  full  range  of  trust  values.  Recommend  a 
range  of  [-1,1]  such  as  that  of  hTrust. 

None  of  these  models  taken  as-is  will  work  for  Cybercraft.  With  some  modih- 
cations,  a  combination  of  the  best  of  all  three,  or  even  a  new  model,  is  a  possibility. 


Table  6.3:  Reference  Framework. 


hTrust 

VTrust 

P2P 

Able  to  form,  maintain,  and  evolve 
trust  opinions 

Yes 

Yes 

Yes 

Incorporates  QoS 

Yes 

Yes 

Yes 

Human  tailored 

Yes 

No 

No 

Subjective 

Yes 

Yes 

Yes 

Highly  customizable 

Yes 

No 

Yes 

Allows  for  transitive  trust 

No 

Yes 

Yes 

Dynamic  trust  changing 

Yes 

Yes 

Yes 

Minimal  resource  demands 

Yes 

Yes 

Yes 

Ability  to  catch  malicious  agents 

Yes 

Yes 

Yes 

Allow  for  degredation  of  trust  over  time 

No 

Yes 

Yes 
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VII.  Conclusions  and  Future  Work 


Trust  expression  in  the  Cybercraft  domain  centers  around  several  key  relation¬ 
ships:  platform  to  payload,  platform  to  platform,  platform  to  node,  and  payload 
to  payload.  There  are  obviously  many  others  to  consider.  Our  continuing  work  con¬ 
siders  which,  if  any,  of  the  current  trust  models  best  express  proof  that  trust  transfers 
from  the  root  of  trust  in  the  payload  to  other  components  in  the  system. 

There  are  many  unknowns  still  to  be  captured  and  analyzed  for  Cybercraft.  The 
goal  for  this  research  effort  is  not  a  network  defense  band  aid  for  USAF  networks, 
but  rather  a  means  to  focus  thinking  about  future  threats  and  capabilities.  In  this 
paper,  we  discuss  various  means  of  capturing  requirements,  specifically  using  the 
software  engineering  techniques  of  use  cases,  threat  modeling,  and  attack  trees.  As 
well,  the  main  research  question  of  trust  was  discussed.  We  expound  briefly  possible 
trust  models  such  as  hTrust  and  VTrust  that  may  provide  a  good  fit  for  Cybercraft. 
Future  work  in  this  are  includes  iterative  requirements  exposition  for  Cybercraft  and 
enumeration  of  trust  relationships  within  the  Cybercraft  domain. 

7. 1  Future  Work 

Cybercraft  is  a  new  idea  for  the  future  of  our  network  defense  and  has  many 
unknowns  still.  The  following  section  discusses  various  work  that  will  help  further 
the  goal  of  implementing  Cybercraft  to  protect  our  defense  networks. 

7.1.1  Requirements.  TCNO’s  and  TCTO’s  are  an  excellent  source  for  gath¬ 
ering  future  requirements.  These  documents  contain  the  daily  guidelines  for  our 
current  network  and  should  be  used  in  helping  define  what  our  future  network  will  be 
like.  Another  area  in  requirements  gathering  is  using  the  brief  use  cases  from  chap¬ 
ter  III  and  creating  fully-dressed  use  cases.  Once  these  use  cases  are  created,  trust 
model  application  is  the  next  step.  Addressing  and  evaluating  the  current  state  of 
our  network  defense  is  important  to  ensure  we  address  any  deficiencies  there  might 
be. 
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7.1.2  Trust.  The  many  components  that  make  up  the  Cybercraft  domain 
will  have  values  to  represent  trust.  Future  work  can  decide  what  value  to  give  a  trusted 
vendor  versus  unknown  vendors  or  vendors  that  did  not  go  through  a  screening  process 
(formal  verification).  As  well  as  vendors,  USAF  networks  extensively  use  third  party 
software,  such  as  A/V  software,  firewall,  etc.  There  needs  to  be  a  way  to  place  a  value 
of  trust  in  these  components.  Communication  lines  must  be  secure  and  trusted  as 
well  and  given  a  trust  value.  One  idea  for  placing  initial  trust  values  is  if  the  product 
offered  goes  through  a  formal  verification  process,  then  the  trust  value  is  1,  if  not, 
it  could  be  0  or  possibly  lower,  even  to  -1.  More  trust  models  need  to  be  evaluated 
to  further  define  the  reference  framework  for  the  Cybercraft  domain.  Evaluating  the 
models  using  the  same  scenarios  and  adjusting  the  parameters  will  help  pin  down 
what  values  are  realistic  for  those  variables. 
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Appendix  A.  Operational-Tactical/Mission  Breakdown 


The  following  tables  are  the  result  of  the  requirements  analysis  from  Chapter  III. 
The  analysis  of  these  tables  are  included  in  Chapter  III. 

Table  A. 2  shows  the  brief  use  cases  created  for  the  defense  priority  of  automated 
attack  interdiction  from  Chapter  III. 


Table  A.l:  Attack  Detection  operational-tactical/mission  break¬ 

down. 


Strategic  goal:  Attack  Detection 

Operational 

Tactical 

Mission 

Detect  Insider  Threat 

Monitor  access 

Ensure  access  is  as  limited  as  possible 

Ensure  a  “need  to  know” 

Log  individual  access  to  highly  sensi¬ 
tive  items 

Ensure  clearances  are  up-to-date 

Examine  physical  security  to  devices 
(server  farm,  unattended  computers, 
wiring  closets,  etc.) 

Maintain  password  policies 

Deactivate  access  immediately  after 
termination 

Monitor  and  respond  to  suspicious  be¬ 
havior 

Record  user  access  24X7 

Detect  physical  threat 

Monitor  access 

Log  individual  access  to  highly  sensi¬ 
tive  items 

Examine  physical  security  to  devices 
(server  farm,  unattended  computers, 
wiring  closets,  etc.) 

Detect  computer  attack 

Determine  source  of 
attack 

Monitor  incoming  IP  addresses 

Monitor  incoming/outgoing  ports 

Monitor  high  activity  sources 

Detection  analysis 

Detect  anomalies 

Analyze  base  traffic  for  XX  months 

Compare  incidents  over  XX  amount  of 
time 
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Table  A. 2:  Automated  Network  Vulnerability  Mitigation  operational- 

tactical/mission  breakdown. 


Strategic  goal:  Automated  Network  Vulnerability  Mitigation 

Operational  Tactical  Mission 

Detect  and  mitigate 

Denial  of  Service 

(DDoS)  attacks 

Monitor  collective 

network  resource 

utilization  and  deny 

attempts  to  usurp 

XX%  utilization 

Monitor  CPU  historical  usage 

Monitor  server  storage  growth 

Monitor  router/switch  activity 

Monitor/analyze  base  incoming  net¬ 
work  activity 

Ensure  global  parameters  are  set  cor¬ 
rectly 

Collect  and  analyze  data  on  network 

performance 

Monitor  overall  network  status,  check 

for  anomalies 

Monitor  specihc  base  network  status 

(i.e.,  a  specihc  base,  unit,  or  squadron) 

Daily/  weekly  sched¬ 
uled  maintenance 

Log  system  crashes 

Ensure  regular  backups  are  occurring 

Use  tools  to  detect  conhguration 

changes 

continued  on  next  page 
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continued  from  previous  page 

Strategic  goal:  Automated  Network  Vulnerability  Mitigation 

Operational  Tactical  Mission 

Ensure  all  patches  are  up  to  date  on 

routers,  switches,  workstations,  etc. 

System  defragmentation 

Scheduled  outage/downtime 

Check  vulnerabilities 

Ensure  global  parameters  are  set  cor¬ 
rectly 

Ensure  proper  conhguration  of  server, 

workstation,  peripherals,  communica¬ 
tions  devices,  and  OS/application  soft¬ 
ware 

Ensure  network  redundancy 

Ensure  ”  hot  swap”  devices  are  available 

Enable  router  hltering  of  known  DDoS 

attacks 

Ensure  workstations, 

network  devices  are 

up-to-date 

Automated  patching 

Ensure  SMS  is  enabled 

Ensure  minimal  exemption  list 
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Table  A. 3:  Automated  Attack  Interdiction  operational- 

tactical/mission  breakdown. 


Strategic  goal:  Automated  Attack  Interdiction 

Operational 

Tactical 

Mission 

Detect  network  attack 

Detect  and  mitigate 
base  external  network 

resources 

Monitor  log  files 

Block  specific  IP  segments  attack  is 
coming  from 

Ensure  router/switcli  ACL’s  are  up-to- 
date 

Cut  off  from  network  compromised  de¬ 
vices 

detect  and  mitigate 
base  internal  network 

resources 

Monitor  log  files 

Ensure  all  patches  are  up-to-date 

Automatic  blocking 

Block  ports 

Start  blocking  a  ’’suspect”  port  when 
traffic  reaches  XX%  utilization 

Block  unused  ports 

Allow  only  certain  traffic  on  ports  well 
known  for  attacks 

Active  deception 

Redirection 

Redirect  to  honeypots 

Documentation 

Logs 

Monitor  logs 

Detect  anomalies 

Table  A. 4:  Network  Attack  Damage  Assessment  operational- 

tactical/mission  breakdown. 


Strategic  goal:  Network  Attack  Damage  Assessment 

Operational 

Tactical 

Mission 

Determine  network  baseline 

Monitor  network 

Log  network  traffic  for  XX  months  to 
create  baseline 

Create  baseline  ACL’s  for  routers  and 
switches 

Implement  standard  desktop 
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Table  A. 5:  Automated  Attack  Reporting  operational- 

tactical/mission  breakdown. 


Strategic  goal:  Automated  Attack  Reporting 

Operational 

Tactical 

Mission 

Documentation 

Track  incidents 

Table  A. 6:  Adversary  Identification  operational-tactical/mission 

breakdown. 


Strategic  goal:  Adversary  Identification 

Operational 

Tactical 

Mission 

Track  IP  addresses/segments  of  known 
attacks 

Analyze  logs  for  trends 
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Appendix  B.  MFR  2008-01-17 


This  is  a  MFR  from  Mr.  Lou  Giannelli,  INOSE  East  Det  3.  We  conducted  weekly- 
meetings  to  hash  out  some  possible  Cybercraft  missions  using  attack/defense 
trees.  This  MFR  is  a  result  of  a  few  examples  Mr.  Giannelli  brought  up  during  one 
of  our  meetings. 

Subject:  Cybercraft  Suggestions 

Submitted  by:  Lou  Giannelli,  INOSC  East  Det  3 

Date:  17  Jan,  2008 

B.l  Background 

As  a  sub  product  of  the  weekly  session  interaction  where  Defenders  have  provided 
Capt  Hunt  with  defense  and  attack  tree  scenarios,  it  has  become  apparent  that  the 
Defenders  can  also  provide  suggestions  for  Cybercraft  capabilities.  This  MFR  docu¬ 
ments  two  suggestions  presented  to  Capt  Hunt  on  today’s  session.  These  suggestions 
represent  possible  solutions  to  mitigate  two  recurrent  problems. 

B.2  Problem  1 

Defenders  routinely  provide  base  technicians  with  technical  details  regarding  sus- 
picious/malicious  network  connections.  The  said  details  are  provided  as  raw  data 
transcripts  in  ASCII  format.  The  average  technician  customarily  is  not  prepared  to 
identify  key  elements  necessary  to  identify  and  validate  questionable  connections. 

Suggested  solution  1.  To  study  the  feasibility  of  enabling  Cybercraft  with  a  parsing 
subroutine  capable  of  enabling  base  technicians  with  a  search  utility  to  locate  these 
key  elements  in  a  raw  data  transcript  in  ASCII  format. 

B.3  Problem  2 

There  are  recurrent  violations  to  current  AFI  and  TCNO  policy.  The  violations 
originate  on  base  internal  users  circumventing  sercurity  policies. 
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Suggested  solution  2.  To  study  the  feasibility  of  enabling  Cybercraft  with  a  logi¬ 
cal  subroutine  capable  of  flagging  an  alert  on  outbound  connections  using  the  listed 
services  when  a  set  of  conditions  are  met. 

This  suggestion  envisions  Cybercraft  enabled  with  a  logical  subroutine  capable  of 
examining  the  3- way  handshake  sequence  on  packets  with  destination  port  21,  and 
a  destination  IP  different  than  the  authorized  sites.  Cybercraft  will  flag  connections 
meeting  these  criteria  with  an  alert. 
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Appendix  C.  Results 


f  I  ~^his  appendix  includes  all  the  results  from  the  scenarios  in  Chapter  VI. 


Table  C.l;  Results  from  a  chain  of  26  agents. 


Recommendation  Chain  Results 

A^C 

0.81 

A^  M 

0.2824 

A^W 

0.0985 

D 

0.729 

A^N 

0.2542 

A^X 

0.0886 

A^E 

0.6561 

A^O 

0.2288 

A^Y 

0.0798 

A^  F 

0.59059 

A^P 

0.2059 

A^Z 

0.0718 

A^G 

0.5314 

A^Q 

0.1853 

A^  H 

0.4783 

A^  R 

0.1668 

A^I 

0.4305 

A^  S 

0.1501 

A^  J 

0.3874 

A^T 

0.1351 

A^  K 

0.3487 

A^U 

0.1216 

A^L 

0.3138 

A^V 

0.1094 

Table  C.2:  Results  from  a  more  realistic  Cybercraft  environment. 


Recommendation  Chain  Results 

A^C 

0.80 

A^D 

0.16 

A^E 

0.032 

A^F 

0.0256 

A^G 

0.0256 
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Table  C.3:  Final  Data  for  scenario  two,  case  one  -  hTrust. 


a’s  data 

Aggregated  Trust  Information 

o,  6, 1, 1, 16] 

Tacit  Information 

[a,  6, 1,1, 10] 

Portfolio  of  Credentials 

[6,  a,  1, 1, 16]5i^(, 

&’s  data 

Aggregated  Trust  Information 

[6,0,1,1,16] 

[6,6,0.34,0.1,12] 

[6,(7,0.25,0.1,14] 

Tacit  Information 

[6,0,1,0.97,12] 

[6,6,0.83,0.1,14] 

Portfolio  of  Credentials 

[o,  6, 1, 1,  lO]^^^^ 

[6,6,0.4,0.1,12]5i,, 

[(7,6,0.4,0.1,14]5k, 

e’s  data 

Aggregated  Trust  Information 

[e,  17, 1,1, 12] 

[6,6,0.4,0.1,12] 

Tacit  Information 

[6,(7,0.97,1,12] 

Portfolio  of  Credentials 

[g,  e,  1, 1,  12]5K9 
[6,6,0.34,0.1,12]5x, 

g^s  data 

Aggregated  Trust  Information 

[(7,6,0.97,1,12] 

[(7,6,0.4,0.1,14] 

Tacit  Information 

[^,e,l,l,12] 

Portfolio  of  Credentials 

[e,5',  1, 1,  lojsi^e 

[6,(7,0.25,0.1,14]5i,, 
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Table  C.4:  Final  Data  for  scenario  two,  case  two  -  liTrust. 


a’s  data 

&’s  data 

d’s  data 

Aggregated  Trust  Informa¬ 
tion 

[a,  6, 1,1,  22] 

[5,  a,  1,1,  22] 

[d,  a,  1,1,  20] 

[a,  d,  0.65, 1,20] 

[5,6,0.34,0.1,12] 

[5,  *,0.13,  0.1,  22] 

[d,  6,  0.34,  0.2, 18] 

[d,*,  0.25,  0.1, 18] 
[d,/,  0.25,  0.1, 16] 

Tacit  Information 

[a,  5, 1,1, 10] 

[a,  d,  0.5, 1,10] 

[5,0,0.97,1,12] 

[d,  a,  0.99, 1, 14] 

[d,  6,  0.75,  0.1, 16] 

[d,  6,  0.75,  0.1, 18] 

Portfolio  of  Credentials 

[5,  a,  1, 1,  22] 5^:^^ 

[a,  5, 1, 1,  22]sKa 

[a,  d,  0.65,  1,20]5k, 

[(i,  (2,  1,  1, 

[e,5,0.4,0.1,12]5x. 

[*,5,0.4,0.1,22]5x. 

[e,  d,  0.4,  0.2,  18]5j^^ 

[*,  d,  0.4,  0.1, 18]5i^. 
[/,d,0.4,0.1,16]si,, 

e’s  data 

/’s  data 

*’s  data 

Aggregated  Trust  Informa¬ 
tion 

[e,  5,  0.4,  0.1, 12] 

[e,d,0.4,0.2,18] 

[e,  *,0.25,0.1,18] 

[/,d,  0.4, 0.1, 16] 

[*,5,0.4,0.1,12] 

[*,d,0.4,0.1,18] 

[*,6,0.4,0.1,18] 

Tacit  Information 

[e,^?,  0.97, 1,12] 

[/,e,l,l,12] 

Portfolio  of  Credentials 

[6,e,0.34,0.1,12]5x, 
[d,e,  0.25,  0.1, 18]5i^, 
[*,e,  0.25,  0.1,  18]5x, 

[d,/,  0.25,  0.1,  16]5k. 

[5,  *,  0.13, 0.1,  22]sKb 
[d,*,  0.25,  0.1,  18]5*^, 
[6,  *,  0.25,  0.1, 18]5ii:^ 
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Table  C.5:  Final  Data  for  scenario  two,  case  three  -  hTrust. 


a’s  data 

6’s  data 

c’s  data 

Aggregated  Trust  Informa¬ 
tion 

[a,  6, 1,1,  22] 

[a,  d,  0.65, 1,20] 

[6,  a,  1,1, 12] 

[5,6,0.34,0.1,12] 

[c,a,  1, 1,20] 

[6,6,0.34,0.1,14] 

[c,  /,  0.25,  0.1, 16] 

[c,  c/,0.25,  0.1,  20] 

[c,  h,  0.25,  0.1, 18] 

Tacit  Information 

[a,  5, 1,1, 12] 

[a,  c,  1,1,20] 

[5,0,0.97,1,12] 

[c,  a,  0.99, 1, 14] 
[6,6,0.75,0.1,16] 

[6,/,  0.75,  0.1, 18] 

Portfolio  of  Credentials 

[5,  a,  1, 1,  l2]sKb 
[c,  a,  1, 1,  20]sk, 

[a,  5, 1, 1,  l2]sKa 
[6,5,0.4,0.1,12]5x. 

[a,  c,  1, 1, 20] 

[e,  6,  0.4,  0.1,  14^]sk^ 
[/,c,0.4,0.1,16]5i^, 
[g,  6,  0.4,  0.1,  20]5Xg 
[h,  6, 0.4,  0.1, 18]5i<-g 

e’s  data 

/’s  data 

g's  data 

Aggregated  Trust  Informa¬ 
tion 

[e,  6,  0.4,  0.1, 12] 

[e,c,0.4,0.1,14] 

[e,^,  1,1,12] 

[/,  6,  0.4,  0.1, 16] 

[c/,  6,  0.4,  0.1,  20] 

[d,e,l,l,12] 

Tacit  Information 

[e,^?,  0.97, 1,12] 

[/,e,l,l,12] 

Portfolio  of  Credentials 

[b,e,0M,0.1,12]sK, 
[c,  6,0.34,0.1,  U]sK, 
id,  e,  1, 1,  l2]sKg 

[c,/,  0.25, 0.1, 16]5i^. 

[c,5(,  0.25,  0.1,  20]5/^^ 
[6,c,0.4,0.1,14]si^^ 

h’s  data 

Aggregated  Trust  Informa¬ 
tion 

[h,  6,0.4,  0.1, 18] 

Tacit  Information 

(none) 

Portfolio  of  Credentials 

[c,h,  0.25,  0.1, 18]5ir. 
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Table  C.6:  Final  data  for  scenario  two,  case  one  -  VTrust. 


A’s  data 

(A^B) 

[0.33,  0.5,  0.0] 

Trust  value 

0.83 

S’s  data 

{B^A) 

[0.33,  0.5,  0.0] 

Trust  value 

0.83 

[B^E) 

[0.25,  0.13,  0.14] 

Trust  value 

0.52 

{B^G) 

[0.17,  0.12,  0.2] 

Trust  value 

0.48 

EA  data 

(E^B) 

[0.25,  0.13,  0.2] 

Trust  value 

0.58 

{E^G) 

[0.5,  0.5,  0.0] 

Trust  value 

1 

G’s  data 

{G^B) 

[0.17,  0.13,  0.14] 

Trust  value 

0.43 

{G^E) 

[0.17,  0.5,  0.0] 

Trust  value 

0.67 

79 


Table  C.7:  Final  data  for  scenario  two,  case  two  -  VTrnst. 


A’s  data 

F’s  data 

(A^B) 

[0.25,  0.5,  0.0] 

{B^A) 

[0.25,  0.5,  0.0] 

Trnst  valne 

0.75 

Trust  value 

0.75 

(A^D) 

[0.13,  0.5,  0.0] 

(B^E) 

[0.15,  0.13,  0.14] 

Trnst  valne 

0.63 

Trust  value 

0.42 

F’s  data 

J’s  data 

(F^D) 

[0.05,  0.14,  0.16] 

{I^D) 

[0.08,  0.14,  0.16] 

Trnst  valne 

0.35 

Trust  value 

0.37 

(F^J) 

[0.05,  0.5,  0.0] 

(I^F) 

[0.05,  0.5,  0.0] 

Trust  value 

0.55 

Trust  value 

0.55 

F’s  data 

F’s  data 

{D^A) 

[0.13,  0.5,  0.0] 

(E^B) 

[0.13,  0.13,  0.2] 

Trust  value 

0.63 

Trust  value 

0.45 

[D^E) 

[0.13,  0.13,  0.14] 

(E^D) 

[0.13,  0.13,  0.2] 

Trust  value 

0.39 

Trust  value 

0.45 

(D^F) 

[0.5,  0.11,  0.15] 

Trust  value 

0.31 

{D-.I) 

[0.08,  0.12,  0.16] 

Trust  value 

0.35 
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Table  C.8:  Final  data  for  scenario  two,  case  three  -  VTrust. 


A’s  data 

G’s  data 

{A^B) 

[0.13,  0.5,  0.0] 

{C^A) 

[0.21,  0.5,  0.0] 

Trust  value 

0.63 

Trust  value 

0.71 

{A^C) 

[0.21,  0.5,  0.0] 

(G^F) 

[0.21,  0.13,  0.14] 

Trust  value 

0.71 

Trust  value 

0.47 

BA  data 

{B^A) 

[0.13,  0.5,  0.0] 

(G^F) 

[0.13,  0.11,  0.16] 

Trust  value 

0.63 

Trust  value 

0.39 

{B^E) 

[0.04,  0.13,  0.14] 

{C^H) 

[0.13,  0.12,  0.16] 

Trust  value 

0.31 

Trust  value 

0.4 

{B^G) 

[0.04,  0.12,  0.2] 

(G^G) 

[0.13,  0.12,  0.0] 

Trust  value 

0.36 

Trust  value 

0.44 

F’s  data 

G’s  data 

{F^E) 

[0.08,  0.5,  0.0] 

(G^F) 

[0.17,  0.5,  0.0] 

Trust  value 

0.58 

Trust  value 

0.67 

(F^H) 

[0.13,  0.5,  0.0] 

(G^F) 

[0.04,  0.13,  0.14] 

Trust  value 

0.63 

Trust  value 

0.31 

(F^C) 

[0.13,  0.14,  0.15] 

(G^G) 

[0.13,  0.13,  0.14] 

Trust  value 

0.41 

Trust  value 

0.39 

F’s  data 

F’s  data 

[E^B) 

[0.04,  0.13,  0.2] 

(F^F) 

[0.13,  0.5,  0.0] 

Trust  value 

0.37 

Trust  value 

0.63 

(F^G) 

[0.17,  0.5,  0.2] 

(F^G) 

[0.13,  0.14,  0.16] 

Trust  value 

0.67 

Trust  value 

0.42 

(F^G) 

[0.21,  0.13,  0.2] 

Trust  value 

0.53 

(F^F) 

[0.08,  0.5,  0.0] 

Trust  value 

0.58 
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Table  C.9:  Final  data  for  scenario  two,  case  one  -  P2P. 


Pe’s  data 

Pg’s  data 

Pe-Pb 

R{Pe,Pb) 

0.0 

Pg-Pe 

RiPg,Pe) 

1.0 

T{Pe,Pb) 

0.67 

nP„Pe) 

0.75 

Pe-Pg 

R(Pe,  P,) 

1.0 

Pg-Pb 

R(P„Pi) 

0.0 

T{P.,  P,) 

0.75 

np„Pi) 

0.37 

PbS  data 

Pq’s  data 

Pb-Pa 

R{Pb,Pa) 

1.0 

Pa-Pb 

R{Pa,Pb) 

1.0 

TiPb,Pa) 

0.75 

T{Pa,Pb) 

0.75 

Pb-Pe 

RiPb,Pe) 

0.0 

T{Pb,Pe) 

0.33 

Pb-Pg 

R{Pi,  P,) 

0.0 

T(Pi,  P,) 

0.4 

Table  C.IO:  Final  data  for  scenario  two,  case  two  -  P2P. 


Pq’s  data 

PbS  data 

Pa-Pb 

R{Pa,Pb) 

1.0 

Pb-Pa 

R{Pb,Pa) 

1.0 

T{Pa,Pb) 

0.75 

T{Pb,Pa) 

0.75 

Pa  -Pd 

R{Pa,Pd) 

1.0 

Pb-Pe 

RiPb,Pe) 

0.0 

T{Pa,Pd) 

0.75 

nPb,Pe) 

0.33 

Pe’s  data 

P/’s  data 

Pe-Pb 

R{Pe,Pb) 

0.0 

Pf-Pd 

RiPf,Pd) 

0.0 

nPe,Pb) 

0.33 

np/,  Pi) 

0.37 

Pe-Pd 

R{Pe,Pd) 

0.0 

Pf-R 

R{Pf,  Pi) 

1.0 

T{Pe,Pd) 

0.33 

T{Pf,  Pi) 

0.75 

PdS  data 

Pj’s  data 

Pd  -Pa 

R{Pd,Pa) 

1.0 

R-Pd 

R{R,Pd) 

0.0 

TiPd,Pa) 

0.75 

T{R,Pd) 

0.37 

Pd-  Pe 

RiPd,Pe) 

0.0 

R-Pf 

R{Pi,  Pf) 

1.0 

T{Pd,Pe) 

0.33 

T{Pi,Pf) 

0.75 

Pd-Pf 

R(Pd,P,) 

0.0 

T{Pi,  Pf) 

0.34 

Pd -Pi 

R{Pd,R) 

0.0 

T{Pd,Pi) 

0.36 
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Table  C.ll:  Final  data  for  scenario  two,  case  three  -  P2P. 


Fa’s  data 

PhS  data 

Pa-Pb 

R{Pa,Pb) 

1.0 

Ph-Pf 

RiPh,Pf) 

1.0 

T{Pa,Pb) 

0.75 

T{Pk,  Pf) 

0.75 

Pa  -Pc 

R{Pa,Pc) 

1.0 

Ph-Pc 

R{PhfPc) 

0.0 

T{Pa,Pc) 

0.75 

T{Ph,Pc) 

0.37 

Fb’s  data 

F/’s  data 

Pb-Pa 

R{Pb,Pa) 

1.0 

Pf-Pe 

R(Pf,  Pe) 

1.0 

TiPb,Pa) 

0.75 

T{Pf,  Pe) 

0.75 

Pb-Pe 

RiPb,Pe) 

0.0 

Pf-Ph 

R{Pf,  Pk) 

1.0 

T(n,Fe) 

0.33 

T{Pf,  Pk) 

0.75 

Pb-Pg 

fl(n,  -p,) 

0.0 

Pf-Pc 

R{Pf,  Pe) 

0.0 

nn,  p,) 

0.33 

T{Pf,  Pe) 

0.37 

Fc’s  data 

Fe’s  data 

Pc  -Pa 

R{Pc,Pa) 

1.0 

Pe-Pb 

R{Pe,Pb) 

0.0 

nPcPa) 

0.75 

nPcPb) 

0.33 

Pc-Pe 

R{Pc,Pe) 

0.0 

Pe-Pg 

RiPe,Pg) 

1.0 

nPcPe) 

0.33 

T{Pe,Pg) 

0.75 

Pc-Pf 

R{Pc,  Pf) 

0.0 

Pe-Pc 

R{Pe,Pc) 

0.0 

TiPc.Pf) 

0.32 

TiPcPc) 

0.23 

Pc-Ph 

RiPcPh) 

0.0 

Pe-Pf 

R(Pe,  Pf) 

1.0 

T{Pc,Ph) 

0.33 

T{Pe,  Pf) 

0.75 

Pc-Pg 

R{Pc,Pg) 

0.0 

T{Pc,Ps) 

0.4 

Fg’s  data 

P  —  P 

R{P„  Pe) 

1.0 

T(P„Pe) 

0.75 

Pg-Pb 

R(P„  Pf) 

0.0 

T{Pg,Pb) 

0.33 

Pg-Pc 

RiPg,Pc) 

0.0 

T{Pg,Pc) 

0.37 
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